Clean up and DRY IOApp implementations

[kapunga]

After taking a few initial passes through the various platform IOApp implementations, I've come up with an approach I am going to take. I plan on adding two layers of traits for a total of three new traits. Here is a rough diagram.

• IOAppCommon - This will contain method signatures common to all implementations, but with different implementation.
• IOAppMultiThreaded - This will contain method signatures common between JVM and Native, as they have a lot of extra bells and whistles not present in the SJS implementation.
• IOAppPlatform - This will contain platform specific method definitions, there will be three different versions of these, one per platform.

I'm attempting to move things around over the course of the PR to the point where all three current IOApp implementations will be identical, at which point create a single definition in shared. A few goals I have in mind as I refactor things:

• De-duplicate methods or add a method signature on a lower level trait so that documentation won't be duplicated.
• Clean up code organization in IOApp to make it more approachable to people trying to understand what's going on in IOApp.
• Hide methods people are better off not over-riding (such as pollingSystem or computeWorkerThreadCount) farther down the type hierarchy so library adopters will be less likely to notice / play around with them. Probably not possible due to bin-compat issues.

This PR will resolve Issue 4333

[djspiewak]

Btw just a quick driveby to say that I think this is the right approach! I think the scaladoc is going to be a bit tricky to resolve, but maybe we can relax our requirements on that one. Also I'd like to ensure that these supertraits don't leak into the public API; ideally users should only be aware of IOApp itself. Should all be doable, just a bit of bincompat needle-threading.