Runtime feature mix-in pattern

The number of potentially desirable features on top of the basic dripline objects (Service and Endpoint) is large and it does not really make organizational sense to put everything into a single class. In some cases, the expected behaviors may even be mutually incompatible.

Rather than trying to create some set of derived classes that implement every possible useful combination, we propose the following pattern:
- additional features are implemented as mix-in classes, each inheriting from the lowest possible base class
- method overrides should never re-implement the logic from the base class, they should use `super()` to re-use that logic (but may alter the arguments passed or process the results returned as appropriate). They should also also not call the parent method directly, but should use super, so that all overrides are called in order when there is possibly multiple inheritance.
- because inheritance order is unknown, every class's `__init__` should be designed in such a way that being called more than once is not problematic
- in runtime config, a user specifies the (ordered) list of mix in classes to be used. The user is responsible for understanding the compatibility implications and ordering of inheritance.
- at runtime, the object creation step should define a new object type with the inheritance set as defined