Add dynamic instantiation contexts

[dfrese]

I would like the see the introduction of a dynamic instantiation context for classes, i.e. given an 'opt' value and an 'app-state' value in a context, then instantiating classes should require only the declared parameters of the class:

(with-instantiation-context {:reaction ... :app-state ...}
  (my-class arg1 arg2))

which should be implemented via a ':dynamic' binding, and be equivalent to

(my-class (reacl/opt :reaction ...) app-state arg1 arg2)

This would have the following advantages:

• The arguments to a 'class call' would be syntactically exactly those listed as the 'params' in the class definition; which it easier to read and understand.
• Abstractions over classes could be simple functions, without the need for a complicated optional 'opt' (and app-state) argument, or even a whole new class. It would bring classes and abstractions over classes on the 'same level', where they are currently very far apart.
• :reaction (or esp. :embed-app-state clauses) and the current app-state value would move closer together. They are usually highly interdependent anyway - one has to think about and change both at the same time.
• Also, esp. the 'opt' declaration is conceptionally nothing that is 'passed' to the class implementation; i.e. it does not have access to it, although it is currently an argument to it. Writing it 'outside' of the class instantiation is much more natural (to me).
• It would enable reusable abstractions over contexts; some may make it easier to prevent the mistake of passing and updating a state differently; some may allow consistent modification of contexts ('append' lenses; map over actions etc).
• Together, this allows for much easier composition of dom elements and classes, as the dom composition and the state composition can be defined in two steps.

This could be added backwards-compatible, if the instantiation function of classes falls back to the current mode, if there is no context set. That legacy mode could be turned off later (or on request per class), to allow for better error messages. Another future option would be to have an implicit default context in the render function; maybe as an opt-in for each class to remain backwards compatible.