CP-2298 Refactor platform-independent pattern to leverage a common utility instance instead of extending a common class

[evanweible-wf]

The current pattern we leverage to produce a platform-independent API is as follows:

• A — The public interface. An abstract class with factories for constructing the correct implementation.
• C — The common piece. Currently this is an abstract common class that implements A and provides as much of the implementation as possible while still remaining platform-independent.
• B, V — The platform-specific pieces. Currently these implementations for browser and VM extend C and implement A and fill in the platform-dependent gaps that C left open.

The one caveat of this approach is that C needs to share certain information with B and V so that they can complete the implementations. This will always be true - the common piece will always need to share state/information with the platform-specific pieces. The options are as follows:

• Use private properties and have C, B, and V be in the same file or part so they can access them. This is impossible. It doesn't work because B and V can't be in the same file or part due to incompatible platforms.
• Use public properties. They will be essentially invisible to consumers since instances are only constructed/used as instances of A, whose interface effectively masks these additional properties. This is what we currently do. The downside is that someone could import the common class C, cast to it, and then access these properties that are meant to be inaccessible. More importantly, it's just confusing. We end up with a set of public properties, some of which are actually public (defined in the public abstract interface A), while the rest are an attempt at "protected" properties - meant only to be shared between internal classes. This makes development within and code review of these classes more difficult than it should be.
• Use a common utility class that houses common, platform-independent implementation logic as well as state that platform-specific implementation logic will need. This allows an instance of the common utility class to be constructed when an instance of B or V is constructed and to be used as a private API. This is what we want to switch to.