Expose public API + make available safely

[nikku]

Is your feature request related to a problem? Please describe

Token simulation is a huge extension. Because of that it has a certain set of issues:

• Large "service footprint": It provides a massive number of services, non of which are namespaced. As a result it is easy to collide with existing (bpmn-js) services declared
• No public API: It does not provide any reasonable public API (no docs on usage either). For proper consumption we shall add API that allows external components to interface with it. feat: add simulation-support module #112 is a start, however it only does a poor mans job.

Describe the solution you'd like

• Investigate if auxiliary token-simulation services can be hidden from sight (using didi __exports__ or proper namespacing
• Investigate clear boundary / public API

Describe alternatives you've considered

Keep what exists, even if it is a little messy.

Additional context

Using didi __exports__ is properly working since since nikku/didi#13; we could consider to integrate it / use it with bpmn-js-token-simulation.

[nikku]

We fell for missing isolation in #139.

[barmac]

Given that there are more issues above #139 (cf. #139 (comment)), I'd like to raise the priority of this. Note that the bugs will affect Web Modeler users (design mode).

[barmac]

So at least the "service footprint" should be fixed.

[nikku]

We quickly discussed with @barmac different solutions and settled down on two options:

• Use didi onboard facilities to isolate the module, including hiding internal services
  • This will prevent external customization
• Prefix internal services, i.e. make behaviors available under a tokenSimulation. prefix
  • This will prevent accidental interference with core bpmn-js, while leaving the ability to customize (externally)

Both approaches would be a major breaking change. I'll investigate further.

[barmac]

Assigning @nikku to investigate in a time-boxed manner.