Remove delays on startup by caching the last few seconds of data by default

[sharpe5]

The only reason that the publisher and subscriber delay by up to a second on startup is to avoid issues on startup. We can avoid all of this by caching the last few seconds of data, until the sockets are properly set up. We could extend this by adding an API call like SubjectReplay(TimeSpan(FromSeconds(5)). We could cache by the seconds value, or the highwater mark, whichever is lower.

For this to work, the subscriber would have to request old values on startup, and the publisher would have to cache outgoing messages in RAM until the publisher is ready.

Ensure that there is always a cap on the number of messages held in RAM, as an easy way to bring down an entire server is for one process to gobble up all of the RAM.

The net effect of this behind-the-scenes magic is that everything just works. We can start the publisher first, then the subscriber, or vice-versa, and we can have reliable subscriptions that don't arbitrarily lose values because they happened to join a network a quarter of a second late.

[sharpe5]

Relates to issue #12.