🪲 PSET: Fixed issue with "out-of-bounds" coordinates

Described above is the issue with PSET before today's new version of BAM.

First, a little technical overview about putting text/graphics on the screen.

Any PRINT/PSET/LINE/CIRCLE/etc. does not actually do anything to the running program's screen.

Print, PSET, CIRCLE, etc.: all statements that put things on the screen, they actually put related data (the colour of affected pixels) into a one-dimensional array, each cell representing a coordinate on the screen.

The goal of doing this?  Performance.  Refreshing the screen is time-consuming.  By only updating the array, screen refresh can be delayed until it makes sense.

Description of the issue

Let's imagine a screen four pixels wide by three pixels tall:

The related array for storing the colour of each pixel:

For every PSET(x,y), the colour value will go into the array's cell number that results from the formula: x + y * screen_width = x + (y * 4).  So say we want to set the pixel colour at screen position (3,1) to (say) yellow, that value would go into array cell 3 + 1 * 4 = 7 (so cell 7 in the array).

Say our program involves an animation (a flying "dot"), and our program thinks that the dot ought to go from screen position (3,1) to (4,1).  Screen position 4,1 would mean array cell 4 + 1 * 4 = 8.  But when the screen is refreshed, the value in cell 8 will be applied to screen coordinate (0,2).

In the new version of BAM, if any coordinate (x, or y, or both) is outside of the boundaries of the screen, then the PSET is completely aborted.  So PSET (4,1), with the screen example above, will not happen.