Refactor connect plugins to be called from wrapper classes

Currently, plugin methods in Connect are called directly from the runtime worker code.
This has some advantages:
1. Low (no) overhead: methods are called directly
2. Traceability: searching for usages of an API method or class discovers all of them in the runtime
3. Shorter stacktraces: caller and callee appear together in stacktraces

And some disadvantages:
1. Need to manually ensure that callers swap in the correct ThreadContextClassLoader prior to each call, and swap it back afterwards.
2. Need to manually ensure that callers handle arbitrary exceptions thrown from plugin methods.
3. Need to manually ensure that the caller is safe if the plugin method never returns (infinite loops).

These three disadvantages have appeared in numerous bug fixes over the last several years, some fixing the same core bug but at different call-sites in the runtime code. We can continue to make this tradeoff and pay for it in crashes, incorrect behavior, and development burden, or can attempt to find a holistic solution that solves these problems once, and makes it easier for later feature development and maintenance.

If we introduce a layer of indirection (wrapper classes) around the different plugins, then we can solve some problems in a central place, or tweak the internal signatures to encourage fewer bugs in the caller code.