GitLab

(Probably should've done this a while ago.  Much earlier in this
research branch, I thought the design of Link/LinkBuilder etc might
get a review... but at this point, its clear there's plenty of
work already do to just sorting out the assembler situation, so
any rethinks of links is *definitely* deferred for future investigation
(if indeed anything ever happens there at all).)

Doing very partial fixes to the example "generated" maps;
just enough to compile.  I'm not intending to use them as a template
for actual codegen later, so their quality is irrelevant at this point.

As has been the priority in other cases, the shorter name should be
reserved for codegen outputs, as those are where we are optimizing for
ergonomics the most.

We use the word "done" as the predicate in iterators; therefore it's
confusing to also use it as a verb for *doing* completion elsewhere.

"Finish" also has the advantage of sounding slightly more active --
which it is, since it's often involved in housekeeping and, well,
*finishing* assignment within the enclosing parent value, as well as
in evaluating validations for types that have them.

When I started typing this, I thought I was going to need it -- or at
least *want* it -- in the recursive bits of map value assemblers.
By the end, it turns out... no, actually, I don't.  Map value assembler
does better just embedding the (very sparse) amount of relevant logic
without abstraction in this case; and it also *couldn't* embed the
anyBuilder regardless, because the anyBuilder embeds the map assembler
which embeds it's value assembler..... Fhwooo.

As you can see in some of the comments, I was also surprised to find
that it currently shakes out that there's no demand at all for an
'anyNode' type.  There could be! -- if we had maps and lists use that
rather space-costly mechanism in exchange for fewer value allocs -- but
at present, we don't.

But even if that supposed dependency path turned out wrong, of course
we still need an 'anyBuilder' regardless -- deserialization often
starts here! -- so, here it is.

More things need to be filled in yet -- for the other scalars I haven't
bothered to stamp out in this package yet, namely -- but these will be
cookie cutter and shan't be interesting.

(Thank goodness.  Been in theoryland for a while.)

There's somewhat more content here than necessary for the benchmark
that's presently runnable; right now only the Map_K_T implementation
is targetted.  I want benchmarks of things with complex keys in codegen
and also benchmarks of the runtime/generic/free impls soon, so
they can all be compared.

There's also a quick fliff of stdlib map usage in a wee benchmark to
give us some baselines...

And there's also a quick fliff of stdlib json unmarshalling for the
same reason.  It's not fair, to be sure: the json thing is doing work
parsing, and allocating strings (whereas the other two get to use
compile-time const strings)... but it sure would be embarassing if we
*failed* to beat that speed, right?  So it's there to keep it in mind.

Some off-the-cuff results:

```
BenchmarkBaselineNativeMapAssignSimpleKeys-8             6815284               175 ns/op             256 B/op          2 allocs/op
BenchmarkBaselineJsonUnmarshalMapSimpleKeys-8             724059              1644 ns/op             608 B/op         14 allocs/op
BenchmarkFeedGennedMapSimpleKeys-8                       2932563               410 ns/op             176 B/op          8 allocs/op
```

This pretty good.  If we're *only* half the speed of the native maps...
that's actually reallyreally good, considering we're doing more work
to keep things ordered, to say nothing of all the other interface
support efforts we have to do.

But 8 allocs?  No.  That was not the goal.  This should be better.

Time to dig...