refactor BuffHandle implementation

[ichthyo]

Change the preliminary implementation's BuffHandle into a real smart-ptr-like handle, then push down the respective API functions from the engine::State interface. Tie the actual buffer provider into the ctor, and erase this information after the handle is created. This would allow us to get rid of all this wired proxying on behalf of the invocation state; my guess is this refactoring will cut down the complexity of the existing node invocation by 50%

But irrespective of this refactoring, the BuffHandle will remain just a wrapper, adding some sanity checks and getting the Lifecycle concerns out of the way; finally, it boils down to a void pointer. Deliberately we don't want to build our own Buffer-Type in Lumiera, because we don't want to build our own media data handling routines. We use Libraries, and those libraries provide the classification and the actual handling.

[ichthyo]

on second consideration, there is a twist regarding performance. If actually BuffHandle is what is going to pushed around to deal with "Buffers", just making this into a "smart handle" isn't enough. Indeed, using a smart handle is a good soultion pattern, but we need to be much more careful regarding the type-like secondary information, which each smart handle carries around. A naive implementation might rely on ref-counting here (maybe intrusive ref counting as a local optimisation). But actually we do not need automatic lifecycle or memory management here -- the usage happens within a very controlled environment.

Thus the actual trade-off is three-fold: cleanliness and simplicity at the usage site versus complexity in management versus speed and lock contention

[ichthyo]

Meanwhile matters are settled thus far as to tell for sure, that the type-like information is a BufferDescriptor, which is comprised of a pointer to the responsible BufferProvider, plus an hashID, pointing to an BufferMetadata entry maintained within the BufferProvider base implementation.

An open question to settle is: what exactly is the purpose of this hashID -- does it point to the BufferMetadata type Key (i.e. represent the kind of buffer), or shall it point to the individual metadata Entry for this specific buffer. From a conceptual point of view, actually it should be the former -- yet the whole point of this embedded BufferDescriptor is to enable building a performant BufferProvider implementation without tangling the engine implementation with those buffer management internals. Thus it might be that we actually need to piggyback implementation related data through this mechanism.

[ichthyo]

BuffHandle is now tightly integrated with BufferDescriptor, both relying directly on a BufferProvider instance. My attempts for a preliminary BufferProvider implementation showed that the embedded hashID really should point to an individual metadata entry -- the type can always be reached as parent of the concrete metadata.

For now this is settled and we'll see how it works out when used within the node invocation...