Move the opcode map: nothing in 0x0X, and room for a return variant

Three blocks move and nothing else changes. Branches take 0x60, subroutines
take 0x70, and the ALU moves up into the 0x10 block the two of them used to
share. Order within each block is preserved exactly - this relocates them,
it does not rethink them.

WHAT IT BUYS IS AN EMPTY 0x00 TO 0x0F. Program Memory that was never
written, or a load that stopped part way and left zeroes in its tail, used
to read as a long run of ADDs: the machine carried on through them, arrived
somewhere unpredictable, and whatever broke there was a long way from the
byte that caused it. Now it faults where it is met:

  Fault: 0x00 at Program Address 0x0004 is not an instruction.

That is the address of the byte after the last real instruction, which is
the difference between a diagnosis and a search. Reserving the whole nibble
rather than just 0x00 means a run into blank memory faults wherever it
starts rather than only when it lands on the right byte. runOffTest records
it, and the block is left empty for whatever turns out to want it.

The other half is room: branches and subroutines had filled 0x10 to 0x1F
between them, so a service return that keeps Q and DP3 had nowhere to sit
next to its family. It has 0x76 waiting now.

Five places wrote an opcode down that the scripted remap did not reach, and
four of them were found by tests rather than by looking:

- secondPass.c lists which opcodes take an address, and firstPass.c knows
  SWI by number. Missing those made XOR read as a branch.
- Asm.asm knows SWI by number too, being the other assembler. Missing it
  made the native and host assemblers disagree byte for byte, which is
  exactly the check that exists to catch a thing known in two places.
- loaderTest.asm carries a hand written payload, and its RETI was 0x19. To
  the assembler those are numbers and to the program they are data, so
  nothing but running it could notice. It says so in a comment now.
- The Assembler Manual prints the bytes hello.asm assembles to, and two of
  them were branches.

The monitor's recorded disassembly moved by exactly the bytes it should:
18 became 72 wherever SWI appears, with SETD and INIB untouched and every
disassembled line still reading the same.

SplitBit Assembler Manual.md

@@ -233,7 +233,7 @@ A third segment may follow them, marked `VEC`, holding the vectors a program nam
 Here is the hello world program from the Programming Manual, assembled and dumped as hex:
 
 ```
-53 50 42 54 01 00 00 00 00 50 52 47 00 11 42 00 12 00 0c d1 00 40 00 10 00 00 26 0a d1 00 ff 44
+53 50 42 54 01 00 00 00 00 50 52 47 00 11 42 00 62 00 0c d1 00 40 00 60 00 00 26 0a d1 00 ff 44
 41 54 00 0e 48 65 6c 6c 6f 2c 20 57 6f 72 6c 64 21 00
 ```
 
@@ -246,7 +246,7 @@ Taken apart:
 | `00 00 00 00` | No features required |
 | `50 52 47` | `PRG` |
 | `00 11` | The Program Segment is 17 bytes long |
-| `42 00 12 00 0c d1 00 40 00 10 00 00 26 0a d1 00 ff` | The Program Segment |
+| `42 00 62 00 0c d1 00 40 00 60 00 00 26 0a d1 00 ff` | The Program Segment |
 | `44 41 54` | `DAT` |
 | `00 0e` | The Data Segment is 14 bytes long |
 | `48 65 6c 6c 6f 2c 20 57 6f 72 6c 64 21 00` | The Data Segment |