Take libakgl 0.8.0, and correct the status range it grew

The pin moves e4aa6a5 -> 149bee0, which is libakgl 0.8.0. Nothing in this
repository changed to accommodate it: both suites pass unmodified, 110 without
akgl and 111 with, and both breakout games run forty seconds headless with no
error line.

**0.8.0 is a whole collision subsystem** -- shapes, pooled proxies, a pluggable
broad phase over a uniform grid, a narrowphase answering with a contact carrying
a normal and a depth, world box queries, and static proxies for geometry that is
not an actor. None of it is called from here yet. This commit is the pull and
nothing else, so that if it has to come out it is one revert of one commit.

**It adds two submodules of its own**, `deps/libccd` and `deps/tg`, so a tree
that updates without `--recursive` configures and then fails compiling libccd.
libakgl's own suite was built and run standalone at RelWithDebInfo before
akbasic was pointed at it: 33/33.

`libakstdlib` and `libakerror` did not move. MAINTENANCE.md requires checking,
and the answer this time is that libakgl 0.8.0 pins exactly what this repository
already pins -- 669b2b3 and 5eaa956 -- so the pairing rule is satisfied without a
bump. Recorded because "we checked and it was already aligned" and "we forgot to
check" look identical in a diff.

**The version floor moves to 0.8.0** with its paragraph, following the
convention in that header of saying what each minor release did and why the
floor moved anyway. Worth knowing for whoever reads it next: `akgl_Actor` grew
fields, so a translation unit compiled against a 0.7 `actor.h` and linked
against 0.8 writes `renderfunc` and `actorData` at the wrong offsets -- and
`src/sprite_akgl.c` writes exactly those two. That is the case the soname cannot
catch and the guard exists for.

**libakgl's reserved status band grew from five codes to six**, gaining
`AKGL_ERR_COLLISION` at `AKGL_ERR_BASE + 5`, so it now owns 256-261 and the
headroom below akbasic's band starts at 262. Four documents said otherwise: the
coordinated range map in MAINTENANCE.md, the comment above the enum in
`include/akbasic/error.h`, the file header of `include/akbasic/akgl.h`, and
chapter 15. That map is the only coordination there is -- nothing enforces a
band boundary at compile time, and the first anybody would know of an overlap is
a status printing under the wrong owner's name in a stack trace.

Also cleaned on the way past: `deps/libakgl/deps/libakstdlib` was showing dirty
in `git status`. It had no local edits -- the checkout was simply one commit
behind the gitlink libakgl records -- so `git submodule update` restored it and
nothing was lost.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EwxGB6TdoVvZ11KQQME9cL
Co-Authored-By: Andrew Kesterson <andrew@aklabs.net>

include/akbasic/error.h

@@ -51,11 +51,17 @@
 
 /*
  * libakerror reserves 0-255 for the host's errno values and its own AKERR_*
- * codes. libakgl claims 256-260. akbasic claims 512-767, leaving 261-511 as
+ * codes. libakgl claims 256-261 -- five codes until 0.8.0 added
+ * AKGL_ERR_COLLISION, six since. akbasic claims 512-767, leaving 262-511 as
  * headroom for libakgl to grow into -- see MAINTENANCE.md for the coordinated
  * range map, which is the only coordination there is: libakerror can enumerate
  * its consumers no better than we can.
  *
+ * **That growth is why the map is worth keeping current.** Nothing enforces the
+ * boundary between two libraries' bands at compile time; the first anyone would
+ * know of an overlap is a status printing under the wrong owner's name in a
+ * stack trace, which is a bad way to find out.
+ *
  * These are absolute constants, never offsets from AKERR_LAST_ERRNO_VALUE, so a
  * libc that grows an errno cannot move them. An enum rather than a chain of
  * #defines so the values stay compile-time integer constants -- HANDLE expands