GitLab

As discussed on the issue thread, ipld.Kind and schema.TypeKind are more
intuitive, closer to the spec wording, and just generally better in the
long run.

The changes are almost entirely automated via the commands below. Very
minor changes were needed in some of the generators, and then gofmt.

	sed -ri 's/\<Kind\(\)/TypeKind()/g' **/*.go
	git checkout fluent # since it uses reflect.Value.Kind

	sed -ri 's/\<Kind_/TypeKind_/g' **/*.go
	sed -i 's/\<Kind\>/TypeKind/g' **/*.go
	sed -i 's/ReprKind/Kind/g' **/*.go

Plus manually undoing a few renames, as per Eric's review.

Fixes #94.

See the changelog for discussion; this had already been on the docket
for a while now.

Key coloration is easy because we already have key emission in one place,
and we already have size computation for alignment separated from emission.
Value coloration will be a little more involved.

Alignment just proceeds around them, leaving appropriate space based on
what other rows needed in order to align with each other.

If a column is absent at the end of a row, the whole row wraps up fast.

The first two example fixtures of what I wanted to achieve pass now :3
That's exciting.

See the package docs in 'jst.go' for introduction to what and why;
tldr: I want pretty and I want JSON and I want them at the same time.

I'm putting this in the codec package tree because it fits there moreso
than anywhere else, but it's probably not going to be assigned a
multicodec magic number or anything like that; it's really just JSON.

This code doesn't *quite* pass its own fixture tests yet, but nearly.
I thought this would be a nice checkpoint because the only thing left
is dealing with the fiddly trailing-comma-or-not bits.

This first pass also completely ignores character encoding issues,
the correct counting of graphemes, and so forth; those are future work.
Most configurability is also speculative for 'first draft' reasons.
All good things in time.

This is something of a little hobby sidequest.  It's not particularly
related to the hashing-and-content-addressing quest usually focused.
Accordingly, as you may be able to notice from some of the comments
in the package documentation block, I did initially try to write this
over in the refmt repo instead.  However, I got about 20 seconds in on
that effort before realizing that our Node interface here would be a
wildly better interface to build this with.  Later, I also started
realizing Selectors would be Quite Good for other forms of
configuration that I want to add to this system... so, it's rapidly
turning into a nice little exercise for other core IPLD primitives!
Yay!  Copacetic.