CL packages landed

[Gerd Möllmann]

I've pushed the branch "pkg" which implements CL packages for Emacs.

Before Someone (tm) gets the idea of blowing up something like Internet
cables instead of pipelines, or we have blackouts here, or whatever, I
thought I'd better make this accessible.

What to expect:

- It runs on macOS with unchanged init file.  I'm not using much, but I
  can say that it works with Helm and Lsp,

- I know of a bug when connecting to Gmail imap using Gnus that's not
  there in master.

- YMMV, it's all only a few weeks old, if at all.


What it does:

- Lisp_Package is a new Lisp type.

- There are 2 predefined packages "emacs" and "keyword", and a
  current package *package* (buffer-local IIRC).

- The whole package stuff is available very early in C. It's initialized
  right after init_alloc.

- Obarrays are gone.  Good riddance. I removed them in a
  backward-compatible way.

- Symbols have packages (symbol-package).  Uninterned symbols have
  a nil package, others have "emacs" or "keyword".

- Lisp_Symbol::next is gone.  So, the size of Lisp_Symbol is unchanged.

- The symbol name of keywords does NOT include the colon.  That turned
  out the only sane way to do it, after some experimentation.

- A number of places in C that assumed that symbol names of keywords
  start with ':' are changed.  On the Lisp side, symbol-name for
  keywords returns a string starting with ':'.  I tried without, but
  that wasn't compatible enough.  There is a cl-symbol-name not
  prepending the ':'.

- Some functions like list-all-packages, make-package are implemented in
  Lisp.  Many others are still missing, defpackage most notably.  I plan
  to add them based on public-domain code from CMUCL.

- Reading symbols and printing symbols is changed.

- A new variable package-prefixes controls if ':' in symbol names is
  interpreted as a separating package names from symbol names.  Default
  is not to.  Astonishingly many code uses such symbol names, the best
  one I've seen is a complete URL 'http://...' :-).


What it is not/does not have:

- Bug-free, for sure, but it is pretty usable.

- Documentation.

- A complete Lisp-side implementation of packages (defpackage,
  use-package, ...

- Tests of the new stuff.  There is a stub under test/, but it doesn't
  do much.

- Fixes for tests of old stuff.  In fact, I haven't run make check yet.
  Weeding out all bugs is currently not my focus.

- shorthand.el is currently not supported.

- Support for pure space is missing.  I have cherry-picked a commit by
  Stefan that removes uses of pure_alloc.  I didn't want to deal with
  pure space, and I can't test it anyway here.

- Other stuff that I currently forget.

And the code is not entirely terrible, at least IMO :-).


Plans:

I think I'll continue using this branch.  No plans, no commitments
though.


Have fun :-)