Context API enhancements

[stevesims]

with the introduction of the ability to call buffers on VSYNC, this potentially allows for some relatively sophisticated buffer-based programs to run on the VDP whilst being separate from programs running on the eZ80 that may be sending commands to the VDP

an example could be a clock that gets drawn at the top of the screen

logically the mechanism to do this is to use a separate context for drawing the clock, but this raises some potentially interesting issues

the primary problem here is that whilst such a program could use it's own context, it does not know which context to return to.

possibly the most straightforward thing to do would be to add a new variant of the "select context" command which could push the previous stack to a stack-of-stacks, and add a complementary variant of "restore" to pop from that stack

an alternative approach could be to provide a mechanism to read which context ID is the currently active context. this might be achievable using the idea of exposing state via "vdu variables" as discussed in #265

additionally it may be useful to add in an ability to detect if a context of a particular ID exists. if a context gets deleted then a program may need to restore that context.

[stevesims]

an alternative approach here to "stack-of-stacks" could be to just allow a version of the "select context" command to accept a -1 context ID to select the previously used context

[stevesims]

going down the "expose state via VDU variables" is arguably the simplest approach, with a variable to indicate the currently active stack ID, and more in keeping with that general idea (which would be a useful feature to have in the VDP)

an issue here though is that currently the initial context is not an explicitly numbered context stack. it only becomes one after a first "select" call is made. there therefore would not be a valid value for an "active context stack ID"

the simplest solution is to give the default context a stack ID, possibly/probably 0. my first thought on this is that it could cause compatibility issues, given that it changes how the numbered stacks works. after some thought I now think that given how the API works though this most likely would not cause problems.

one issue with this idea is that the context stack API allows for the deletion of all numbered stacks. deleting the currently active stack just means you are using a stack that is removed from storage. you could thus end up without a valid value for "active context stack ID". this could be mitigated by just preventing the current stack ID from being deleted, ensuring there will always be an active ID.

the alternative approach would be to have the mechanism to read a vdu variable, or conditionally execute a buffer based on a VDU variable, able to understand a "null" variable, possibly/optionally allowing it to be defaulted it to a given value. whilst this may be a useful feature in and of itself (if the "read VDU variable" is actually a "read feature/text flag") it would mean that a buffer program to temporarily select a buffer would first need to ensure that the current buffer is saved, adding a fairly significant amount of complexity. therefore the idea to have a default ID, and to ensure that there will always be an active stack ID, would be the easier approach for user programs