ability to pick behavior of session overwriting, contention

[TYoung86]

(per PR #55)

While using an atomic write should resolve session corruption due to concurrent writes, there is still the issue of the picking the correct writer.

This can be avoided by allowing the first reader to issue a lock if it has an intent to modify, but this requires a significantly different behavior for the implementor of session-file-store.

I propose adding a write-conflict behavior option, a user provided selection function, and cancellation handling by fs events.

Write conflict behavior could default to last write wins (what currently happens), with other options available; last read wins, first read wins, first write wins, and/or user selection.

A user provided selection function could pick a winner or provide a custom merge result or defer an existing behavior dynamically.

Where the execution of the conflict resolution would occur will depend on the behavior, and in the case of user selection will need to decide when (and where) to execute.

This could be on successive reads under lock (preemption), first and/or successive writes under semaphore (cancellation), and successive writes upon modified time mismatch (in post).

Are there other execution scenarios?

The option to lock and silently block to avoid contention all together should probably also be implemented. Lock breaking (e.g. check if the owner is still alive, maybe a timeout) should also be implemented if the locking implementation depends on a lock file or other mutex that can lose it's owner (preferably should not, and use OS/FS level locking primitives).

While using a different session store provider such as sqlite may solve these issues, it should not be necessary, and is undesirable in certain situations.

Testing should be kept in mind during the implementation to allow the injection of fake events.