Future thread manager tasks

This ticket is a collection of various features and cleanup work that we should eventually do for the thread manager framework.

# Features

- the ability to stop a thread manager, which should wait for all threads and executor services to stop
- the ability to create a child thread manager (such that when the parent is stopped, it waits for the child to be stopped, but not vice-versa)
- the ability to allocate various threads and executors to "resource buckets". I.e. some threads should be given unlimited use of their own threads, and others may have to share resources with other low priority jobs.

# Cleanup

- the threading framework should go into the base module
- the thread manager should be part of the platform context
- the packages for the thread manager and the thread framework should be better integrated (right now it's kind of ad hoc)
- remove QueueThreadPool
- Make it so that QueueThread doesn't expose all queue methods (it should just have basic methods for inserting)
- finish adding automated metrics to thread framework classes
- figure out a way to simply the thread configuration classes
- perhaps stop supporting scheduled thread pools entirely... the official API is half baked

No files, tests, or entry points are named. Start by locating the thread manager and thread framework classes, then select one proposed feature or cleanup item and confirm its current ownership and module layout. Done would require a defined scope, implementation, and focused tests for that single item.

Written by the indexing model from the issue text.