GitLab

So far everything we've used these mixins for was generating based on
a *schema.Type*.  This isn't true anymore: representation nodes are
still nodes, so most of the same helpers are useful for the same
reasons and we want to reuse them... but then now they're not always
directly related to a particular reified schema.Type anymore.

Correspondingly, these helper templates were using the .Type.Kind
property as a shortcut to avoid more args, but that is wrong now:
for example, if we're going to generate the representation node for
a struct with a stringjoin representation, the closest thing we would
have to a schema.Type is the struct; but that kind clearly isn't right.
So, now that is another property passed internally to the embeddable
helpers (the helper-helpers, I guess?), and affixed by the helper
rather than provided by a schema.Type param (which, again, we no
longer have).

Note for more future work: this is the first time that a "TypeIdent"
property has shown up explicitly, but it's also *all over* in the
templates in a defacto way.  So far, my policy has been that extracting
consts from the templates isn't a priority until it proves it has a
reason to also be handled *outside* the immediate locality of the
templates (because if we pulled *everything* out the templates will
become a thin unreadable soup; and doing bulk sed-like edits to the
templates is fairly easy as long as they're consistent).  Now, that
criteria is probably satisfied, so more refactors on this are probably
due very soon.

And one more further sub-note on that note: I'm not actually sure if
some of these types should have a "_" prefix on them or not.
"$T_NodeBuilder" currently doesn't -- meaning it's exported -- and that
might not be desirable.  I started them that way, so for now I'm just
sticking with it, but it's a thing that deserves consideration.
(It might be nice for godoc readability if there's a clear hint that
the builders exist; but also, at present, there's no guarantee that
their zero values are at all usable, and that should be cause for
concern.  Other considerations may also exist; I haven't attepmted to
weigh them all yet.)
Signed-off-by: Eric Myhre <hash@exultant.us>