Allow write path template on FileStoreBase to include .

[callumforrester]

Fixes #1146

FileStoreBase "validates" its write path template (unless a read path template is also supplied). In this context that means it checks if the store's root is an ancestor of the template, but does not allow . as the write path.

The use case for this is making a file store write to its own root.

Changes in this PR to address this:

• Make FileStoreBase consider the value of root (or simply .) a valid write path under root.
• Refactor common behaviour out of read and write path properties
• Add suite of tests to validate that read and write paths are processed properly in a variety of use cases
• Check that behaviour holds whether root/write/read paths are passed in the constructor or set after object creation
• Add a minimal dummy implementation that is used in the tests without needing to run an IOC

Note: If we decide that . should be explicitly disallowed, then the first point is easily reversible and the others are hopefully still useful.

[callumforrester]

Paging @tacaswell and @DiamondJoseph

[tacaswell]

The refactoring seems good and I think I'm sold on this. The requirement to include the root twice was never great (if I recall correctly, there was a path dependency is that we had read_path and write_path for a while and then we added the notion of root so added it in a way that would not break stuff on the floor).

---

A different API that we talked about at the time was a root level integer to say how many levels to consider as part of the root but we (incorrectly) judged that was more likely to end up with incorrect values than including the part of the path that was the root directly.

[tacaswell]

We do not seem to check that self.reg_root is actually absolute which leaves the thing we are actually trying to prevent (which is relative paths leaking out into the documents).