feat: split implementation

[Julusian]

This splits most of the implementation to be loaded in from Companion. This implementation is expected to be on disk, and is loaded from a path specified by the environment variable MODULE_API_PATH.

Instead of the IPC types being the stable api, the signature of the function loaded from MODULE_API_PATH and the CompanionInstanceApi interface are now the stable api. For now the IPC types haven't changed, so modules using an older version will still run, but at some point these versions should be blocked.

The benefit of this split is to avoid needing to update @companion-module/base when bugfixes are needed to some of the logic we run inside of modules. For example #33 had to be applied to every module, and #37 had to be applied to some modules which were impacted.
In this new flow, both of these fixes would have been handled solely inside of Companion.

This is a partial step backwards to be more like how it was done in older versions of Companion, but it keeps the benefits of the typings and the InstanceBase class being loaded from this npm package, and decouples where both sides must reside on disk.
For library authors this will be seamless as nothing has changed in the api we expose to them.
Going forward, I expect that this library will contain very little other than typings and some utilities. It may get some code to do type translations, or it may start having alternate methods added to CompanionInstanceApi which newer versions of this library will use.
It will still retain the benefit of providing a typed and versioned api, and allow us to limit/control the api exposed to modules depending on what version of this library they use. In doing so, unless a module digs into places they shouldn't, then we will have the same guarantees on compatability as before.