It takes advantage of the internals, using a string to mimic a memory address. But since it's those internals that cause the leak in the first place, I think this is a reaonable way to do the test. However, it could be confusing without signifant study, so leave a note for my future self to explain how this works and why.
If you specify a state with a rule that point to a state that also has a rule that eventually point back to the first state, well, you'll get a memory leak. The fix is to weaken references to states in rules. Many thanks to @glasswalk3r for finally chasing down the proper fix, which in turn allowed me to do some poking to reproduce the leak as a test failure so that it can stay fixed. Closes #6.
Made the mistake of referencing the referenced, which meant that no FSA::Rules object was ever destroyed until program exit. Nasty memory leak! So use `Scalar::Util::weaken()` to weaken the circular references. This allows the objects to be destroyed when they exit scope. Resolves #3.