* Optimised intoXX functions

Rewrote intoXX functions to mainly rely on intoHL, as the HL instructions are smaller and faster. Also removed some redundant push and pop instructions. I edited the given unit tests to test these, and they seem to work as expected.

* Doesn't use self-modifying code

The number of bytes is the same as my previous attempt, with 11 more cycles in intoHL, so although I don't feel as clever this time it's still a good optimisation. I found an equivalent method for intoDE, however relying on intoHL still allows for  `ex (sp), hl` to be used in intoIX, which is smaller and faster.

* Update core.asm

* Tried harder to follow coding convention

Added tabs between mnemonics and operands, and replaced a new line I accidentally removed.

Found via `codespell -q 3 -S ./tools -L splitted`

scas, it's not needed any more.

It allows to see much more easily where the action happens on the screen.

Looping inside ReadC broke the shell's hook logic. We have to
return immediately when nothing is typed.

Also, make tests run in a *BSD environment

Sure, it's a bit slower, but it prevents a lot of hard to debug
problems. I don't have to want to remember "don't use IX if you
have any blk* calls". Let's optimize I/O later.

A routine to conveniently read lines from TTY. Extracted from
shell. Will be used in other places.

That is, send current chr selection, and then, send LF.

This avoids having "ghost" chr selection sticking around.

This allows for outputting a character selection before it's given
through GetC. That allows a pad-oriented character selection scheme.

Still a bit rough around the edges, but still, works rather well.

This hook is called during every iteration, allowing regular screen
refresh when video is involved.

Make ASCII_BS (sent when driven through kbd) make the same thing as
ASCII_DEL. Also, don't crash on filling the buffer.

We'll make them uppercase when we'll add support for shift.

It previously returned success!

When there's a mismatch, retry up to a certain number of times.

This makes random problem related to assembling big kernels go away! But
it also make SD card reading much slower...

For now, this achieves nothing else than wasting cycles, but this is the
first step in enabling CRC verifications (CMD59).

I think that this is where my random problems with assembling large
kernels from SDC come from: bad data that isn't detected. If that
happens when PGM loads programs in memory, then anything can happen.

`sdct`, when ran often enough, will error out or corrupt away (go
crazy)...

It would always load one byte less than told... This time it's right on
the money :)

Calling `load` would always read one more byte than specified. Also,
make `0` mean `0x100`.

Also, make `0` mean `0x100`.

I don't know why I haven't noticed it wasn't protected. It must have
been behind many random problems I've been having...

That was an interesting bug. It didn't cause a problem in emulation, but
in an RC2014 on an SD card, an include that didn't end with two newlines
would cause an infinite loop.