What this allows is for idStrings that are separated by
dashes or underscores to be considered one whole string
rather than a bunch of tokens mixed together.

This is necessary for examples such as a-node-graph[text].
Now, the last part of the idString 'graph' will be read as
part of the NODE_STRING token rather than attempting to add
a GRAPH token to the idString.

This was never really used and had many things wrong with it.
I believe that if a hex was provided in the diagram specification,
the alphanum grammar would break it up into a BRKT and NUM token
and use the first line with the addVertex() function.

Second, the styleLink grammar provides the exact same functionality
with the linkStyle keyword.

Third, updateLink() expects an array of nums, not a hex digit.

Fourth, no documentation is provided on this grammar statement existing.
Fifth, the unit test does not work in version 10.2.4

Similar to what was done in the class diagram parser,
this will allow string tokens to appear in any state.
This is especially helpful, because it will simplify the
code and any future refactoring

…n production

…oduction

…ition

Previously, you were allowed to define a class called 'default'
but were not allowed to use it because the classStatement grammar
expected an alphanum, which did not include the word DEFAULT

Originally, I thought this was necessary to prevent parsing
the token as part of an edge. I forgot that the token will always
be separated from the link/edge by the node id. Added an unit test
for an edge case to be certain.

This attempts to maintain the current behaviour.
Previously, because HREF contained a space and called
a state, the href token was able to be placed in the
beginning of node ids (because it wouldn't conflict
without the space). We require the space to keep that
behaviour.

…kens

This will ensure that alphaNumToken does not lose any of
the previously used tokens in its definition. The same
tokens were added to textNoTagsToken explicitly, because it used to
have alphaNumToken in its definition before I removed it.

Previously, textNoTagsToken and alphaNumToken had many tokens in
common in their definition. To avoid grammar conflicts, the
alphaNumStatement grammar was created. However, I found this
unintuitive and was an extra step just to avoid repetition in
the definitions.

I opted to have repetition in the definitions of textNoTagsToken
and alphaNumToken and it be explicitly clear right away, rather than
have extra grammar statements like alphaNumStatement which don't look
like they do anything at first glance