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.

I wanted this for use in codegen work: in particular, as part of
generating error messages.

Note the comment on the case for unions.  I still go back and forth on
this topic; see some recent previous commit messages on this branch.
(I think I'm slowing coming around to "unions act like maps", and it's
just that most library code chooses to jump over them transparently,
because that's the least-odd path for resolving NodeBuilder questions;
but it remains the case that none of this is settled for sure yet.)

The schema.Type objects don't have a `Kind() ReprKind` method.  That
was just a bad idea.  I didn't try to fix it; I just nuked it.

The new schema.Type.Kind() method docs include a description of why
it's incorrect to wish for a either a single or a statically known
ReprKind for a type.

(Context mention: the previous commit was also a wind-up for this.
And technically, I'm still winding back up the mental stack here:
this had to get straightened out because I wanted to start poking
codegen for structs; and then I had beef with the TypeStruct.tupleStyle
field being a bool; and then fixing that pointed out that the current
Type.ReprKind methods were kinda insane... yaks!)