FileStore Risks Corrupting Sequence Number File

In testing against a poorly behaved destination our target sequence number managed to turn negative at some point (which is another story).

The implementation of `FileStore.setSeqNum()` assumes a fixed length string being persisted of 23 characters -- 10 each for the sequence numbers and 3 for the delimiter.  Unfortunately, if the sequence number is negative, a format string of "D10" is going to return 11 characters, the extra being the negative sign.

A negative target (or sender) sequence number results in a 24 (or 25 if both are negative) character string.  When the values are no longer negative, writing a 23 character string over the top leaves 1 (or 2) extra character(s) on the end of the target sequence number.

When attempting to restore state from this corrupted file the target sequence number is not only off by an order of magnitude (or two), but it may (and did) exceed the maximum value of an integer, causing a unrecoverable parse exception on startup.

Appending a pad of two extra spaces on the end will ensure there are no lingering characters.  Doing so in this manner looks a little dirty but is the most performant solution (vice a format string of "0000000000  " or other string concatenation techniques).