Fixes for half-blocks and quadrants, and new checkerboards

[PhMajerus]

Summary of the Pull Request

This is a very small update to prepare for unified mosaics, but it touches some existing glyphs.

The full block █, half blocks (1×2 and 2×1) ▀ ▄ ▐ ▌, and quadrants (2×2) ▖ ▘ ▗ ▚ ▙ ▝ ▞ ▛ ▟ ▜ are designed to be aligned on the same grid. Half blocks are used to complement the quadrants to get all possible 2×2 mosaics.
As explained in #644, there was a problem with some of these not being aligned on the same grid, preventing them from getting aligned properly when combined.
In preparation of sextants (2×3) and octants (2×4), as well as separated quadrants and sextants, this update uses a single set of coordinates for the subpixels of all mosaic characters.
This is the only pull request I have planned that requires changing existing glyphs, all the future ones only add new glyphs, so I pushed this one as a small one to make it easier to review as it probably requires more attention, the next ones will contain lot of glyphs, but based on programmed patterns.

References

This is the first and most difficult step towards providing the sextants as requested in #607, and octants discussed in #647.
While this update doesn't resolve either of these issues, it is the most difficult part to build a unified coordinates grid for all mosaics, which will then allow me to add the sextants and octants very quickly (they are ready, so I'm talking within days).

PR Checklist

• Closes Half and quadrant block elements are not aligned on the same grid #644
• CLA signed. (I believe I did during Build 2020)
• Requires FONTLOG.txt to be updated
• Requires /images/cascadia-code.png and/or /images/cascadia-code-characters.png to be updated <- Not updated as the changes are minor and wouldn't be visible, next updates will be much more interesting!
• I've mentioned this to @aaronbell in Problem adding GDI+DWrite glyphs pair for contribution (help needed) #704 and he seemed enthusiastic.

Detailed Description of the Pull Request / Additional comments

Many of the existing half blocks and quadrants used y=707 for their vertical center. This has been changed to y=873 for GDI versions and y=710 for DWrite versions. This is geometrically correct considering their bounding boxes are respectively [0,2226},[1200,-480] and [0,1900],[1200,-480].
These new coordinates have been tested with other mosaic characters and render correctly.

This update also adds a few characters of the Symbols for Legacy Computing, especially interesting for terminals:

• U+1FB95 Checker Board Fill (full block size)
• U+1FB96 Inverse Checker Board Fill (full block size)
• U+2427 Symbol for delete square checker board form (Apple ][ style)
• U+2428 Symbol for delete rectangular checker board form (TRS-80 style)
• U+2429 Symbol for delete medium shade form (Amstrad CPC style)

The two first ones are part of Unicode 13, while the 3 other ones have been accepted for Unicode 16 on 2022-Jan-26 (https://www.unicode.org/alloc/Pipeline.html).

Images of the Character(s)

Note the existing half-blocks and quadrants are now consistent, but seem to be a bit off, with their middle y separation too high. I'm not sure if Windows Terminal handles them as special cases, or if some hinting is involved and changes the pixels snapping.
For testing, I included U+1F67F and U+1F67E to be identical to U+259A and U+259E respectively, they are literally using <component base=.../> to reference the existing characters, and yet they render differently, they are properly separated in 4 equal parts while the quadrants are not.
To be able to include all mosaics, we really need all of them to be rendered similarly, half blocks and quadrants are used as sextants and octants to avoid duplicating existing characters.
So I suggest we update using the new coordinates and quickly add sextants and octants, and hopefully the Terminal team can unify how they handle all characters, or simply remove any blocks-specific code they added when Atlas wasn't able to render them well yet. The new characters that Windows Terminal doesn't handle as special case seem to render really well now.

Validation Steps Performed

Visual test on 100% and HDPI 200% displays, going through basically every zoom level using Ctrl+MouseWheel in Windows Terminal, and verified the glyphs in the built file using VTT.
I actually have sextants and octants built into a test version to verify how they all fit together and render. The pull requests are separated to make it more manageable to review the changes, but I have 386×2 other mosaic characters to submit.

Note the characters are not hinted, I wouldn't even know where to start, but they seem to behave similarly to the existing mosaic characters. They look great as it, I'm not sure whether simple geometrical shapes need hinting. Be careful though as all mosaics need to fit together, half blocks must align with quadrants, both must align with octants, half left and right must align vertically with all as well as with sextants, etc...
Whenever a new higher definition grid is introduced, they only include the missing pattern and reuse the equivalent existing patterns from existing lower resolution mosaics.

[PhMajerus]

@aaronbell
I didn't succeed in refactoring the quadrants files and settled for just fixing the coordinates they use in the existing files.
The next mosaics (for next pull requests) are a lot of glyphs, so I used the same convention as the Unicode documentation, with a prefix to define which set of mosaics it is and a suffix to specify which pseudo-pixels are on, using a string of numbers where each pseudo-pixel has its own number and the sequence stays short and very easy to identify.

The sextants will be blockSextant-[digits], where digits are taken from the following grid:

+---+---+
| 1 | 2 |
+---+---+
| 3 | 4 |
+---+---+
| 5 | 6 |
+---+---+

And the octants will be blockOctant-[digits], where digits are taken from the following grid:

+----+----+
|  1 |  2 |
+----+----+
|  3 |  4 |
+----+----+
|  5 |  6 |
+----+----+
|  7 |  8 |
+----+----+

I wanted to refactor the quadrants similarly to make it easier to handle all mosaics, as follows:

+-+-+
|1|2|
+-+-+
|3|4|
+-+-+

upperLeftBlock -> blockQuadrant-1
upperRightBlock -> blockQuadrant-2
lowerLeftBlock -> blockQuadrant-3
lowerRightBlock -> blockQuadrant-4
upperLeftAndLowerRightBlock -> blockQuadrant-14
upperRightAndLowerLeftBlock -> blockQuadrant-23
upperLeftAndUpperRightAndLowerLeftBlock -> blockQuadrant-123
upperLeftAndUpperRightAndLowerRightBlock -> blockQuadrant-124
upperLeftAndLowerLeftAndLowerRightBlock -> blockQuadrant-134
upperRightAndLowerLeftAndLowerRightBlock -> blockQuadrant-234

But I ran into errors and couldn't find where the script referenced the older names.
While this is not required for my next submissions, I would recommand going that route when you work on the great overhaul.

[PhMajerus]

Here's a test to confirm the new coordinates are right, showing sextants using the same pseudo-pixels grid:

Also a nice demo of what can be achieved with sextants and VT colors.

---

And here's a test of the unified mosaics coordinates used for quadrants, sextants, and octants:

curl https://raw.githubusercontent.com/PhMajerus/ANSI-art/main/Unicode/Blocks%20tables.txt

[PhMajerus]

I'll include a characters picture in the next pull request, but here is an overview of what I have planned.
This pull request contains the first blue set of characters. Other groups show more quadrants, sextants, octants, separated quadrants and sextants, seven-segment digits, and large type pieces.
All of these are par of the legacy computing blocks.

[PhMajerus]

After some more days of testing with a custom build, it seems the quadrants with the old coordinates align better with the new ones I have prepared.
I don't know why using all the same coordinates doesn't work, there must be something else tweaking those glyphs.

I'd still recommend we modify them to use the same coordinates for all mosaics for better maintainability, but I'll close this pull request and start over with one that only provide new glyphs, leaving the existing ones as they are for the meantime.