clean-up BufferProvider base implementation

[Ichthyostega]

As Lumiera Architect,
I insist on a clean-up in the implementation structure of the Buffer Provider Protocol,
to keep this central hub in the Engine in a maintainable shape.

resolve shortcomings of prototyping

This interface and protocol (#824) is assumed to play a crucial role at the link between render processing and backend services. It was shaped, incrementally, by a prototyping process many years ago — together with the similar »Output Slot Protocol«

[Ichthyostega <prg@…>]

In c21ddc1/Lumiera:

BufferProvider: looking for ways to disentangle the implementation (see #1410)

The outward interface has stood the test of time quite well.
But the back-side towards the implementation is a tangled mess,
presumably due to being developed from prototyping code: the
actual implementation is completely overgrown by diagnostics
and test instrumentation, since running in unit test setup
was the only actual usage of this code ever since.

My first attempt with decomposing into a decorator-chain failed.
Thus the new line of attack is to introduce two implementation
pillars right from top-level

• BufferStage : the state and metadata handling
• BufferStore : the storage backend

These are defined as nested interfaces, and the further refactoring
starts with subclassing everything, nested as it is.

[Ichthyostega]

As an aside, this refactoring removes the last remains of a smart-ptr-like BuffHandle — it is now only a handle, tied to the underlying BufferProvider, which allows to query and transition state, but it does not provide and autmagic registration / de-registration any more. The operator* is removed,
and buffHandle.accessAs<TY>() became the regular usage pattern.

This change should be placed into context:
At inception time, I worked under the assumption that the core Render Engine will be implemented in plain-C, basically using void* for everything. The »buffer-handle« was thus meant to provide some layer of automatisation and sanity checks on top. Meanwhile, the design of the engine has changed dramatically: the engine has no longer any direct knowledge about processing — while, on the other hand, invocations are represented as fully typed functors, which are constructed and provided from within an adapter Plug-in for some external Media processing library. This construction allows to raise type- and sanity checking up one level, into the Builder, without ever breaking the chain of strict typing.

[Ichthyostega]

Attach to parent #1411 (Aliasing of Buffer TypeHandler instances).

[Ichthyostega]

Attach to parent #1415 (setup proxying through BufferProvider).

[Ichthyostega <prg@…>]

In ce5f7d5/Lumiera:

BufferProvider: new reworked implementation validated and complete (closes: #1410)

After an extended round of analysis and cascading reworks,
the long-standing discrepancy between OutputSlot and the
Buffer Provider Protocol (#1395) has finally been resolved.
The foundation for this success was laid by means of a restructured
implementation within BufferProvider – which has now been
successfully completed and validated.

[Ichthyostega]

Attach to parent #819 (diagnostic OutputSlot).

[Ichthyostega]

Attach to parent #851 (buffer-provider protocol (test)).