Add directory based open & create calls

[movitto]

Since in the examples and most implementations NuDB will use 'nudb.[dat|key|log]' files to persistently store the DB, this patch simplifies this 'default' scenario, allowing the end user to create and access a database given the directory in which those files reside.

Thus the user can now open the db like so:

store.open("/path/to/db/", error_code)

[vinniefalco]

This is a reasonable quality of life feature in principle, but it should not require accessing private members of store. It should be implementable as a free function using only public interfaces:

open_dir(store, "/path/to/db/", ec);

[movitto]

Hey @vinniefalco I'm afraid I'm not following. The basic_store public/private access control is still in effect and this patch just overloads nudb::create and nudb::basic_store#open to facilitate dir based initialization. Can you help me understand your design principles behind preferring external wrapper methods to extending the base_store interface?

[vinniefalco]

See: https://www.reddit.com/r/cpp/comments/262it3/effective_c_prefer_nonmember_nonfriend_functions/

[movitto]

OK @vinniefalco thanks for the link, I just bought a copy of "effective c++" for future reference!

I incorporated the feedback you had for this patch from this PR and #75. Specifically:

• open_dir is now a function in the nudb namespace, constructing the default file paths under the specified base dir, and then invoking the 'open' method on the specified store
• filesystem helpers were embedded in the project so as to remove the dependency on 'boost::filesystem'. In addition to the provided 'path_cat' function, the following others were added: 'path_exists', 'is_dir', 'mkdir_p'. I should note that while I attempted to support win32 functionality I do not have an environment to test it on.
• a file.ipp implementation file was added to implement the previous
• tests were added to the test suite verifying directory based creation and access
• default path helpers were made inline, when the string_type/string_view patch is available I can rebase this ontop of that

Let me know if there's anything else!