[Tracking issue] Document initialStates

[RReverser]

Currently initialStates are just told to be "strings, each being the name of a tokenizer state" and only ["data state"] is mentioned (as a default, it doesn't appear explicitly in tests).

Such definition is a bit vague for consumers that want to use the provided test format.

[RReverser]

This is especially important because changes / new additions currently arrive silently (e.g. #92 introduced CDATA section state) and there is no clear list of states that must be exposed.

[inikulin]

I guess the best solution will be to use state names as they are declared in spec. And then just point to the spec in the README for the comprehensive list of possible state names.

[RReverser]

@inikulin That could work but tests use only few of these states, exposing every one of them would be quite inconvenient (if not impossible) for many parsers. I'd prefer an explicit list in README that would be updated if any new entry state is added.

[gsnedders]

Yeah, I agree with @RReverser. Especially if someone reviews #83 and we can build some lint for this! I think all we need are the states the tree constructor moves us to, as everything else should be reachable from one of those?

[gsnedders]

And yes, I believe they should just use the names as declared in the spec. I think we at some point just used lowercased spec names (for… reasons?).

[RReverser]

I think we at some point just used lowercased spec names (for… reasons?).

Yeah, it was one of implicit breaking changes that led me to creating this issue.