osthread internals: Let's cut the Thread class code in half?

[Denis Feklushkin]

Hi!

Well, maybe anyone remember that from time to time I push PRs 
aimed at supporting more operating systems and bare metal.

Once again, just like many years ago, I'm looking at the 
core.thread.osthread code. Now it's because of updating from the 
upstream of my "dfruntime" fork 
(https://github.com/denizzzka/dfruntime/). And this is still very 
difficult due to the OS-dependent structure of our code.

What I mean is Thread class code (and few other places): it 
contains many of version() branches like:

```d
~this() nothrow @nogc
{
     if (super.destructBeforeDtor())
         return;

     version (Windows)
     {
         m_addr = m_addr.init;
         CloseHandle( m_hndl );
         m_hndl = m_hndl.init;
     }
     else version (Posix)
     {
         if (m_addr != m_addr.init)
             pthread_detach( m_addr );
         m_addr = m_addr.init;
     }
     version (Darwin)
     {
         m_tmach = m_tmach.init;
     }
}
```

Let's assume that we add a couple more OSes here? This discredits 
our beautiful version() branching - using them this way means not 
making it easier, but confusing the code.

Idea is simple: let's make two Thread classes, for Windows and 
for Posix.

But previously (a long time ago, more than 5 years ago, I think) 
I already proposed similar cuts. (Moreover, I already have my own 
version of runtime, cut as I need it - see above). The main 
obstacle was that druntime code cannot be in a situation where we 
have two identical classes in our source tree, but compiled 
depending on the choised OS using `version()`), with the same 
method names. This is because classes need to be documented, but 
the documentation will also have to be duplicated and our doc 
parser cannot handle such a situation.

Has anything changed since then? Have community come up with any 
tricks to get around this problem?

Currently I think we are very close to supporting arbitrary OSes 
and bare metal targets. In fact, the problem voiced here is the 
only serious obstacle.
(And, presumably, the decision will also bring us closer to 
support wasm.)
As for me, it would be cool to close this gestalt.