Support for Moddable XS via injectable interface to access maps

[cmidgley]

In PR #12 (now closed), the suggestion was to expose a hook from DI to abstract access to the maps and remove Moddable-specific code from the implementation. This new PR takes that approach using the container constructor to optionally inject a storage implementation.

1. A new options? property on the container constructor, containing an optional injectable implementation for the container maps (customContainerMaps: IDIContainerMaps). When specified, it is used for container map access else it defaults to simple Maps as before.
2. Minor adjustments to support the new hook by changing all map access to use the this.#containerMaps object (which then has the three maps).
3. A minor change when a singleton is registered more than once. Before this change, registering a new implementation for a prior-registered (and allocated) identifier would not allocate a new instance matching the new registration implementation. This change clears the prior instance upon re-registration to ensure a new allocation of the updated implementation is used. I can see debating the need for this feature, or the behavior (losing a prior allocated singleton vs. not using the new implementation), but I imagine few people encounter this edge case. For my use case, it's critical because my modules self-register at load time, and then my unit tests may change the registration (for mocking), so I need the most current singleton registration to be the active one. If there is a need for the prior implementation, we now have the extensible options object on the constructor and can easily make the behavior selectable.
4. Included a manifest.json file as required Moddable to import and build.

This is running well (with a custom Moddable map-hook and default hook for Node) across our code base, and passing all our tests.

Let me know if this approach is closer to what you were thinking or if we need to adjust further.