Refactor Overlay, HTTP::Server for universal port

These refactorings are required to support the universal port.
Reviewers: @miguelportilla, @scottschurr

Ignore the top 3 (eefc5d9..0ebc9ee) they are from another pull request.
I see two possibilities here for the destructor:

1.  Wait until the children clean up.
2.  Notify the children that they need to clean up on their own, and then detach them.

Neither solution is always the right answer.  1. ensures that nothing gets destructed out from under the children, that they may need in the process of cleaning up.  But it serializes destruction which is slow.

2. Can be much faster, but must be carefully designed such that the children can shut down without UB even if the parent destructs first.

In a nutshell, this engineering decision is the reason ~thread() calls terminate() today if asked to destruct a joinable thread.  There is no universal right answer:  join or detach.

We could also try to close everything down prior to the destructor.  This is analogous to having a close() function on std::fstream, even though ~fstream() calls close() anyway. This still isn't a great solution though.  If close() throws an exception (leaving the fstream open), ~fstream() is still going to be faced with an ugly situation as the stack unwinds.  And that's just error reporting.  If we are concerned that close() is going to take a long time, then either we're waiting just prior to ~fstream() being called, or waiting from within ~fstream().  Again, ultimately no clearly correct solution for every situation.