Rename Schunix to SchOS; the kernel becomes SchIFT

Removes the "-unix" element and with it any trademark exposure to The
Open Group.

The split follows the ecosystem layout: SchOS is the system, and the
kernel has its own name. Kernel-identity strings are the only places
that take SchIFT -- uname(2) sysname, /proc/version, and the two licence
sentences that say "kernel" outright. That is what every Unix does here:
`uname -s` on Linux reports the kernel, not the distribution. Everything
a user reads as the product -- panic screen, boot menu, error prefixes,
docs, LICENSE, NOTICE -- is SchOS.

schunix.img is schos.img, the logo assets and the musl TLS patch are
renamed, and __SCHUNIX__ is __SCHOS__ (the define and the patch that
consumes it moved together).

Two things the rename broke, both found by the bootcheck suite:

  - shmtest wrote "SCHUNIX-MMAP-OK" with a hardcoded length of 15 and
    compared it back by hand-counted offsets (m[3]=='U', m[14]=='K').
    The shorter marker left the write running two bytes past the literal
    and the compare reading past the data, failing a file-backed mmap
    that was working correctly. Now written and compared through one
    constant with sizeof.
  - bootcheck asserted a 31-byte file after appending to
    "hello-from-schunix"; the shorter string makes it 29.

Both are the same mistake: a string literal whose length is written out
somewhere else. Full suite green -- base, Tty, Ps, Sock, Fb, Usb, Evdev.

tools/bootcheck.ps1

@@ -1,4 +1,4 @@
-# Headless boot check: run Schunix under QEMU, type commands at the shell, and
+# Headless boot check: run SchOS under QEMU, type commands at the shell, and
 # assert on what actually comes back.
 #
 # Booting to a prompt proves nothing on its own -- a filesystem can mount and
@@ -22,7 +22,7 @@
 
 param(
     [switch]$Fb,
-    # Boot schunix.iso from an emulated optical drive with NO hard disk
+    # Boot schos.iso from an emulated optical drive with NO hard disk
     # attached, which is the only way to prove the ISO is self-contained.
     # Needs `make iso` first.
     [switch]$Iso,
@@ -54,7 +54,7 @@ param(
 
 $ErrorActionPreference = 'Stop'
 $root = Split-Path $PSScriptRoot -Parent
-$hda  = Join-Path $root 'schunix.img'
+$hda  = Join-Path $root 'schos.img'
 # The root filesystem. SchFS is the only root there is, so this is not a
 # choice -- a kernel handed anything else on device 1 panics in forkret().
 $hdb  = Join-Path $root 'build\schfs.img'
@@ -67,7 +67,7 @@ Remove-Item -Force $log -ErrorAction SilentlyContinue
 # on its own, and every one of these has broken at some point while the boot
 # still looked perfectly healthy.
 $commands = @(
-    'echo hello-from-schunix > /tmp/bc.txt'
+    'echo hello-from-schos > /tmp/bc.txt'
     'cat /tmp/bc.txt'
     'echo second-line >> /tmp/bc.txt'
     'wc -c /tmp/bc.txt'
@@ -161,7 +161,7 @@ $commands += 'echo MARKER-DONE'
 # The ISO run attaches no hard disk at all. That is the whole point: a kernel
 # that still quietly needs one would boot happily here otherwise, and only
 # fail on someone else's machine.
-$isoPath = Join-Path $root 'schunix.iso'
+$isoPath = Join-Path $root 'schos.iso'
 if ($Iso -and -not (Test-Path $isoPath)) { throw "no $isoPath -- run 'make iso' first" }
 
 $drives = if ($Iso) {
@@ -222,7 +222,7 @@ $psi.Arguments = ($drives + $usbDevices + $monitor + @(
 $psi.RedirectStandardInput = $true
 $psi.UseShellExecute       = $false
 
-$what = if ($Iso) { 'schunix.iso, no hard disk' } else { "hdb = $(Split-Path $hdb -Leaf)" }
+$what = if ($Iso) { 'schos.iso, no hard disk' } else { "hdb = $(Split-Path $hdb -Leaf)" }
 Write-Host "==> booting ($what)" -ForegroundColor Cyan
 $p = [System.Diagnostics.Process]::Start($psi)
 
@@ -372,12 +372,16 @@ function Expect($pattern, $what) {
 }
 
 Expect 'MARKER-DONE'              'shell stayed alive through every command'
-Expect 'hello-from-schunix'       'a file written on the root filesystem reads back'
+Expect 'hello-from-schos'       'a file written on the root filesystem reads back'
 Expect 'second-line'              'appending to that file works'
-# 19 bytes of "hello-from-schunix\n" plus 12 of "second-line\n". The exact
+# 17 bytes of "hello-from-schos\n" plus 12 of "second-line\n". The exact
 # number is the point: an append that silently truncated still produced a file,
 # and only the byte count said which one.
-Expect '(?m)^\s*31\s'             'append extended the file rather than replacing it'
+#
+# It follows the string above, so changing that changes this -- the SchOS
+# rename shortened "hello-from-schunix" by two characters and this check went
+# red on a filesystem that was working perfectly.
+Expect '(?m)^\s*29\s'             'append extended the file rather than replacing it'
 Expect '(?m)^copy\.txt'           'a copied file appears in a new directory'
 Expect '(?ms)copy\.txt.*rmdir'    'rmdir removed the directory without an error'
 
@@ -393,7 +397,7 @@ Expect 'vga: display controller'  'the display driver found its aperture'
 
 Expect 'schfs: mounted'       'the kernel mounted SchFS as the root filesystem'
 Expect 'init: ready'          'init came up on a SchFS root'
-Expect 'label:\s*schunix'     '/proc/schfs reports the volume label'
+Expect 'label:\s*schos'     '/proc/schfs reports the volume label'
 Expect 'root_objectid:\s*16'  '/proc/schfs reports the root object id'
 Expect 'dir\s+bin'            'the root directory really contains bin/'
 # / is the mounted volume, so mounting that same device again must be
@@ -415,7 +419,7 @@ if ($gens.Count -ge 2 -and
 }
 
 if ($Fb) {
-    Expect 'id\s+schunixfb'        'FBIOGET_FSCREENINFO identifies the device'
+    Expect 'id\s+schosfb'        'FBIOGET_FSCREENINFO identifies the device'
     # 800x600 is what boot/stage2.S asks VBE for. Asserting the numbers rather
     # than just "the ioctl returned" is the point: the old code path returned
     # success with an untouched buffer, i.e. a 0x0 screen.