adds support for jump, conditional jump, copy, and consolidate, with placeholders for jump with offset calls

API calls added to bitmap/sprite APIs to allow for the creation of bitmaps based on a buffer
also a call added to select bitmap based on buffer ID, allowing us to break the current 256 bitmap limit

next step is to integrate this with the existing bitmap system, making all those bitmaps be buffer backed, and to ensure that bitmaps (and sprites) properly handle buffer deletion

all existing bitmap API calls now use buffered commands API buffers for their backing stores

existing code should all still work.  bitmaps will be assigned buffers in the range &FA00-&FAFF (64000-64255).  these buffers are accessible to the buffered commands API and thus are editable

still some work to be done ensuring this is safe, mostly in terms of how sprites operate.  also bitmaps should really be cleared when their backing buffers are cleared, but that does not currently happen

command added for buffer reverse

takes an option value to allow for future expansion.  currently only `0` is supported, which will mean the bytes in each stream inside a buffer will be reversed.  (the streams stay in-order.)

rather than being ignored, jump to buffer -65535 is now a “jump to end”, which will exit current stream.  it is ignored for the ez80 VDU stream

also fixed compiler warnings

buffered commands that had offered support for 24-bit offsets now support “advanced” offsets, indicated via the same flag bit

when offsets are “advanced” they are still a 24-bit value (as before), but if the top bit of that value is set then the following 16-bit value indicates the block within the buffer that the offset applies to

support for jump with offset added

as an added bonus, call with offset added too as it’s needed when jumping from the ez80 VDU processor, so we may as well expose it

breaking change - call current buffer no longer rewinds the buffer.  this functionality was there because we didn’t have a jump

added bonus - tail call optimisation added to bufferCall

reverse command now supports differing value sizes, including arbitrary value sizes, as well as chunking

split can now be used to split into separate buffers, and to split into a given number of chunks by width (allowing for instance a bitmap to be split into columns)

spread calls added to spread blocks from a buffer into other buffers

split and spread support versions to specific target buffer IDs, or to start from a specified target ID

tail-call optimisation fixed (would never have been used as it was - oops)

common buffered code refactored for reuse

jump to buffer 65535 with an offset is now “jump within buffer”, rather than “jump to end” (which it remains for jumps without an offset)

bitmap and sprite reset calls now also reset the current bitmap/sprite

initial/reset bitmap ID is now 64000, i.e the 8-bit bitmap 0.

added checks to verify that allocations have happened inside vdu_buffered and vdu_sprites

changed bitmap command &21 (create bitmap for buffer) to be more consistent with its corresponding command 1, so it no longer takes a buffer ID and the format moves to the end - both commands thus now work by using a “select bitmap” command first to set the bitmap buffer to use, both accespt width and height as their first 2 parameters, and then comes either the bitmap data stream (for command 1) or the format (for command &21)

and some minor logging enhancements

adds one new audio sample command to “create sample from buffer”, which expects a buffer ID and a format byte

the “select waveform” command now understands waveform type of 8 (AUDIO_WAVE_SAMPLE) which then expects the 16-bit buffer ID for the sample.

samples added using the existing API will get stored in bufferId &FB00 up

sample object changes

allows for samples to be modified in-place, thus you can create a sample for a buffer, and then do things like reverse the blocks in a buffer and hear those changes reflected on sample playback