Pruning should not look at location names to determine which ones are inconsistant

The theoretical definition of error states and inconsistant states do not care about the label given to a state. Thus the location label in an automaton should not matter, but currently it does.

In the example below, a user has given one location the name `inc` (for some unknown reason). But this location is completely consistant, as one can delay infinitely long.

When pruning is applied on this example, the edge labeled with `a!` is removed, see below.

No source file, test, or entry point is named in the issue. Start by locating the pruning implementation and the consistency/error-state logic, then reproduce the attached automaton with a location named `inc`. Done means pruning no longer uses location labels and the `a!` edge remains when the state is theoretically consistent.

Written by the indexing model from the issue text.