Implement split/3 for splitting and joining lists

This utility predicate will be used internally to split multi-line
comments into single lines for processing structured comments.
Use strings consistently in split/3 tests

This just makes it clearer to readers that I'm following the same
pattern in each test case.
Make split/3 reversible w/o data loss

This changes how split/3 handles empty lists and lists with
trailing separators.  Under the old behavior,

    split("",   10, A),
    split("\n", 10, A),
    A = []

That gave us ambiguity when joining [].  Should we produce "" or "\n".
It also gave us no way to distinguish trailing separators.

The new behavior is

    split("",   10, [""]),
    split("\n", 10, ["",""])

which lets us reverse both cases unambiguously and gives us
a means to distinguish trailing separators.

Incidentally, this semantics reduces the number of clauses needed
to define split/3.
Document split/3

This predicate will shortly move to its own module.  Until then, it
should be documented.
Move split/3 to list_util module
Experiment: process comments

This makes me do most of the heavy lifting.  I'd like to have
library(pldoc) do that so that I don't have to recreate the wheel.
Experiment: reuse pldoc code for modes
Experiment: cleaning up comment processing code
Simplify comment processing with library(charsio)

I initially avoided library(charsio) because of a strange warning: "No
source location!?"  There seems to be no way around that, short of
changing SWI-Prolog source code.
Assert predicate modes as facts in mavis module

These facts will eventually be used for term expansion macros
Reliably detect structured comments

I tried using pldoc_process:is_structured_comment/2 but pldoc_process
includes a bunch of PlDoc code that breaks our comment hooks.  The DCG
for recognizing structured comments is small enough I just copied over
the relevant portions. I used library(dcg/basics) where possible.
Give test script a funky type

Having two separate types in the test makes it easier to see that
mavis is adding the correct type assertions.
Modules opt-in to comment expansion

Ideally, SWI-Prolog would automatically call a hook in my module after
my module was consumed with use_module.  That would let me do this
automatically.  Until that's offered, modules consuming mavis must
call activate/1 to turn on comment expansion.
Correct a documentation typo
Add type assertions based on structured comments

As with all mavis types, this only happens during development time
(when optimizations are off).  I added a test example showing this
work for DCGs as well as standard predicates.
Use when/2 instead of freeze/2

When using the/2 with DCGs, it's quite common for a value to be a list
whose tail is a variable.  That's fine but prevented type assertions
like the(codes,X).  As soon as X was bound to a partial list, we'd run
the type check and it failed.

Instead of triggering type checks on unification, wait until the value
is fully ground.  In nearly every case, error:has_type/2 definitions
require the arguments to be ground.  This change breaks the few
remaining cases.  If it becomes a problem, I can fix it once I have
some concrete examples.
Move pack documentation to readme

This follows the pattern I use in my other packs.
Update documentation

Use the same format I use on my other packs.  Describe automatically
converting PlDoc comments into type assertions.
Move README to pack root

Having the README in the pack and repository root directory makes it
visible to GitHub and SWI-Prolog online pack infrastructure.  I still
need a symlink in prolog/ so that "gift doc" can find the readme file.