Add full compiler toolchain, libc, examples and reference docs

First substantive commit: the entire Sprinter C compiler tree on top of
the bare README+gitignore initial commit.

What's in here:
  bin/sprinter-cc        — driver script invoking SDCC + linker + mkexe
  libc/                  — Sprinter-specific libc layer over ESTEX/BIOS
                           (conio, gfx, io, mem, stdio + headers)
  runtime/               — crt0 variants (default/small/banked/minimal)
                           + heap + bank trampolines
  toolchain/             — mkexe (SprintEXE packer, C + tests)
  examples/              — 30 demo programs (gfx, file I/O, env, time, …)
  lib/Makefile           — builds the libc archive (sprinter.lib)
  docs/                  — converted Sprinter manuals + asm reference samples
  third_party/           — solid-c reference compiler dump + sdcc setup script
  release_docs/          — packaging / release notes

gitignore overhaul:
  • Drop dangerous blanket patterns: *.asm (would hide docs/samples/*.asm)
    and *.exe (case-insensitive match was hiding third_party/solid-c/*.EXE
    on macOS APFS).  Replaced with examples/*/*.{asm,exe,…} and lib/*.lib.
  • Restore tracking of toolchain/mkexe/tests/{one,big}.bin — those are
    INPUT fixtures, not build outputs.
  • Collapse the duplicated SDCC/C/Sdcc sections into one section per
    concern (build outputs / vendored / OS-junk).
  • Add .sprinter-cc-*/, build/ (catches lib/build/ too), .claude/.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

third_party/solid-c/DOC/REL.RUS

@@ -0,0 +1,137 @@
+Последняя редакция: 7.05.2004
+
+
+                ФОРМАТ REL-СОВМЕСТИМЫХ ОБЪЕКТНЫХ ФАЙЛОВ
+
+
+  Объектные файлы REL-формата фирмы Microsoft, представляют собой битовый
+поток. Отдельные поля в битовом потоке не выровнены на границу байта,
+кроме элементов, описанных ниже.
+  Использование битового потока для объектных файлов уменьшает их размер,
+сводя к минимуму число обращений к диску для чтения/записи данных.
+
+  Имеются два основных типа: Абсолютный и Перемещаемый. Первый бит служит
+индикатором типов. Если он равен 0, следующие 8 бит загружаются как абсо-
+лютный байт. Если первый бит равен 1, следующие 2 бита определяют 4 типа:
+
+     00b       Спец-элемент (описание ниже).
+
+     01b       Перемещаемый Код. Значение следующих 16 бит (2 байта)
+               необходимо прибавить с текущему значению счетчика адреса
+               Кода.
+
+     10b       Перемещаемые Данные. Значение следующих 16 бит (2 байта)
+               необходимо прибавить с текущему значению счетчика адреса
+               Данных.
+
+     11b       Перемещаемая Общая область (код+данные). Значение следующих
+               16 бит (2 байта) необходимо прибавить с текущему значению
+               счетчика адреса Common-области.
+
+
+Спец-элемент(ы) содержит:
+
+    ■ контр. поле из 4-х бит номеров элементов 0..15.
+
+    ■ не обязательное A-поле. Содержит 2 бита типа адресации cseg,
+      dseg,common (кроме абсолютного) и 2 (4 у extended REL) байта
+      значения.
+
+    ■ не обязательное B-поле. Содержит 3 бита (5 у extended REL)
+      длины имени и самого имени идентификатора.
+
+
+Общее представление спец-элемента:
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+    1 00b   xxx   yy  nnnn  mmmm    zzz + имя идентификатора
+                  --------------    ------------------------
+                      A-поле                 B-поле
+
+      xxx     4 бита контр. поля (0..15 номера элементов, см. ниже)
+
+      yy      2 бита типа адресации (cseg/dseg/common)
+      nnnn    16 бит значения (адрес)
+      mmmm    16 бит дополнительно, при расширенном REL-формате
+
+      zzz     3 бита длины имени (5 бит при расш. REL-формате)
+      ...     имя идентификатора
+
+
+Номера элементов контрольного поля
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Номера элементов только в B-поле:
+
+     0      -  имя метки, на которую имеется ссылка
+     1      -  имя блока COMMON
+     2      -  имя прогр. модуля (program name)
+     3      -  request-имя файла (request library search)
+     4      -  элемент расширения. См. примечание.
+
+Номера элементов в A-поле и B-поле:
+
+     5      -  размер COMMON  (элемент только для A-поля ?)
+     6      -  внешняя цепочка:
+                 для A-поля: адрес головной цепочки
+                 для B-поля: внешнее имя
+     7      -  точка входа метки:
+                 для A-поля: адрес располож. метки
+                 для B-поля: имя метки
+
+Номера элементов только в A-поле:
+
+     8      -  External - offset. Used for JMP and CALL to externals.
+     9      -  External + offset. The A value will be added to the two
+               bytes starting at the current location counter immediately
+               before execution.
+    10      -  размер области Данных.
+    11      -  счетчик памяти сегмента (ORG cseg/dseg/common).
+    12      -  адрес цепочки. A is head of chain, replace all entries
+               in chain with current location counter.
+               Вход последней цепочки имеет нулевой адрес.
+    13      -  размер области Кода.
+    14      -  конец программного модуля (end program), далее идет
+               выравнивание до границы байта.
+
+Этот элемент не содержит ни A-поле, ни B-поле:
+
+    15      -  конец файла
+
+
+Примечание по элементу расширения:
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+C-поле элемента расширения имеет формат B-поля спец-элемента, но область
+имени не содержит имя идентификатора, как в B-поле. Вместо него здесь
+находится один байт типа (сигнатура) элемента расширения, далее следует
+от 1 до 7 байт дополнительной информации.
+
+Таким образом, каждый элемент расширения имеет формат:
+
+   1 00b  0100b   zzz  i  jjjjjjjj
+                  ----------------
+                      C-поле
+
+     zzz        любые 3 бита (000b представляется как 8).
+                (001b у асма SOLID).
+
+     i          8 бит типа (сигнатура) элемента расширения.
+                (0FEh у асма SOLID).
+
+     jjjjjjjj   zzz-1 число байт информации. Значение зависит
+                от типа i.
+
+
+Это присутствует только в одном элементе расширения:
+
+     zzz        010b (2)
+
+     i          X'35' тип (сигнатура) оверлейного сегмента COBOL
+
+     j          номер COBOL-сегмента - 31h  (цифровой формат номера)
+
+  Когда линкеру встречается сигнатура оверлейного сегмента, текущее число
+оверлейных сегментов устанавливается в значение j+31h (симв. формат номера).
+Если предварительно существующий номер сегмента не был нулевой и включена
+опция /N (сохр. файл с заданным именем), то область данных записывается на
+диск в файл. Имя файла равно текущему имени программы, с расширением файла -
+Vxx, где "xx" две hex-цифры номера сегмента j+31h (симв. формат номера).