GitLab

This first crossed my mind when considering whether it might be a good
idea to export the concrete implementation types of the 'basicnode'
package (see previous couple of commits -- it mostly had to do with the
question of whether we could reuse more code and shrink the size of
packages emitted by codegen)... but even though that's resolved to a
pretty solid "nope", it still makes sense to have a consistent name
prefix pattern here... and we'll probably encourage and expect to see
similar conventions in other packages (including in codegen, if we
add a handy-constructor-funcs feature to that).

Turns out there was a lot of tech debt already accumulating very very
rapidly due to the earlier whimiscal choice to lump the new basicnode
implementations and the demo-codegen implementations into the same
packages as benchmarking and research on this branch began.

The basicnode package is now extracted cleanly, and exists in the
'node/basic' path.  This 'basicnode' package is the equivalent of what
was formerly called 'ipldfree' on the master branch.

The demo codegen content is now under 'node/gendemo'.
Note that it is BROKEN in this commit; there was too much there to
clean up and address in one commit, and this one has already become
quite large and includes a bewildering number of moves as well as
finer content rearrangements.  Fixes will come in next commit(s).

(Why?  Well, the demo codegen content leaned on the basicnode types
for string and int.  Turns out this actually opens *quite* the
can of worms when you try to rectify it.
At the surface level, the basicnode package's types aren't exported.
Could we export them?  Well, sure.  Except that's only half the trick.
Can we export the *assemblers* for those types?  Well, sure.  But...
Can we export the 'w' fields for those assemblers for those types?
**NO** -- this is where it all breaks down -- if those fields are
exported, we lose all control over all immutability everywhere.
Shoot...?  Very shoot.
One clearly correct solution to this is to generate new types for
all of the primitive scalars in every codegen output package;
the downside, obviously, is that's a bit verbose in resulting code.
There might be another very alexandrian solution to this gordian knot:
exporting the basicnode package's types after all, but not their
assemblers; then leaning further into their implementation detail
of being implemented as typedefs rather than strictly enclosed structs,
and having every part of codegen types that handle primitive leafs
directly perform and manage the relevant casts.  The bigger picture
wisdom of this has not been completely analyzed yet.)

The 'impls' path has in general become 'node'.
This will stay this way when we finally merge over core on master;
all the current 'impl' (without the s; sigh) paths will become 'node'.

Numerous new HACKME files have appeared; some are splits of old ones
to account for the new package splits; some are hoisted and polished
from what were previously commentstorms in the code; some are
completely new.  There are also a few new package-scope godocs.

The benchmarks and tests are rearranged and much (much) improved.
Naming is more consistent; and things are consistently extracted
to the 'node/mixins/tests' package, and imported and used from there.
(If you want all the same benchmark info as before, you'll now have
to run benchmarks from several different packages.)

And some misc fixes in others (inconsistent method ordering where I
updated existing files, mostly).

Lists still coming up; being a recursive kind, those have much more
involved code.

(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.

This removes all the shitty placeholder `panic("no")` calls which
previously occupied this area, and gets us one step closer to being at
the quality level where we can merge this into core.

Also, a short template file to make it easier to stamp out the rest of
these for the remaining kinds.  No automation; not worth it.

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.

They don't reduce line count, but they do make lines much shorter,
and increase consistency, which are worth it.

There's some very similar things already in the codegen system,
though under a different name ("kindedRejectionHelper" something).
I've realized the utility also exists beyond codegen.

Codegen can in the future be updated to use these (and in the process,
emit noticably fewer bytes of generated code).

(There could be concerns about codegen output getting overly fragile
and dependent on core library versions by reusing more code like this.
However, I don't think that applies here: It's already going to be
fragile if any of the actual error types change; being fragile if the
mixins (which are *almost* entirely about those) change is effectively
the same thing, it just saves a lot of output size.)

I would collapse all these uninteresting methods into one line each
rather than three lines each if I could... however, the golang
formatter's (rather incogruous?) rule about breaking long lines in
this *particular* case strikes.  Turns out in this corpus, for example,
the `plainInt.LookupSegment` declaration *just* crosses over the
length which forces a break, even though none of its siblings do.
Sigh.

The previously specified behavior has turned out to be *remarkably*
annoying; much more so than I initially expected.  It's both not
particularly pleasant to handle as a user; and even more unexpectedly,
has turned out absolutely infuriating as a library author.
(You can see how the early work on these new packages has simply
resorted to a placeholder panic there, because the reject-carrying
thunks cost an irritating amount of unimportant work.)

The mapIteratorReject and listIteratorReject thunks have replicated
too many times already, and this count is indicative of a problem:
I'm not replicating them again into this new generation of interfaces.
Nope.  Nuked.

These parts, at least, are super cookie-cutter.

Picking them off the shelf and putting them in the "done" bin as I go
on the 'any' stuff, which as mentioned in previous commit, is a bit
more 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...