Inherit the state sets and methods of the supertypes' specs

The verifier now accepts @stateset(name = "phase", value = {...}) and a
state written as a value of its set, phase(this) == open, which it reads
as open(this), and phase(this) != open as !open(this). The parser took
such a from for a condition on every state, so the diagram lost its
transitions.

A comparison of a one-argument function with a state, in either order,
is now that state, and != negates it, wherever the shorthand is read:
from, to, constructors and factories. Conditions keep the form the spec
wrote. Each state machine carries stateSetName, the name given to its
state set, or null when it has none, so a client can label the diagram
with the name the verifier's messages use.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

open(this) != false is not phase(this) != open: it means open(this), so
its complement drew the transition from the other states. Only a
comparison that is itself a state value is read as its negation.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Read named state sets and states written as values of their sets

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…covered

A StateRefinement with a to but no from was also drawn from the initial pseudo state, like a constructor, when the
method had other StateRefinements with from. The verifier reads it as from = true, so it already goes from the states
the others do not cover; only constructors and factory methods enter the state machine. entryTransitions is kept,
always empty, so that clients still compile.

Closes #18

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…beside others

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Draw a StateRefinement without from only from the states it leaves uncovered

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>