Make kp::Algorithm and kp::Sequence internals protected for subclassing

[troelsy]

At Veo Technologies, we are prototyping Kompute integration in a GStreamer pipeline so our custom GStreamer elements can leverage Vulkan in a simple and efficient way.

In order to make GStreamer and Kompute work together, we have to modify the Sequence and Algorithm classes a bit. For kp::Algorithm we need to change the input and output buffers on our Algorithm for each execution, as GStreamer gives us new buffers with every call. In order to do this, we changed the member variables from private to protected and created a new Algorithm subclass that inherits from kp::Algorithm.

For kp::Sequence we did the same thing, making the member variables protected. GStreamer implements a mutex lock you need to acquire before calling vk::Queue::submit, so our child class of kp::Sequence will acquire and release the lock before submitting to the queue.

This PR only changes private to protected for member variables. If you think others may benefit from our locking/unlocking, I can make a separate PR for that too.

[axsaucedo]

Super interesting. This sounds quite interesting. WOuld be keen to learn more about other nuances here. To be honest we have also explored also ways to access the internal components, so we can integrate / extend.

If you sign DCO we can merge.

[troelsy]

Tried another rebase, let's see if that fixes the DCO

[axsaucedo]

Great - it did, thanks - LGTM

[ahem]

@axsaucedo I added an issue with some more detail here: #454