Support device DAX

[RobDickinson]

Testing so far has been against filesystem DAX, which is fine for development and basic testing. But for real stress testing on real hardware, we want to be using device DAX whenever possible.

There are a few tweaks to KVTree needed to open a DAX device successfully, and the the rest of the code works just fine. I've made these quick changes by hand in the past for my own testing, but now I'm running often enough on device DAX to want to get this all merged in officially. This part is easy.

The larger consideration is what this means for pmemkv administrative workflows. There are now three ways that KVTree can be opened -- device DAX, filesystem DAX with existing file, and filesystem DAX without an existing file. It's only the last case where the size parameter has any meaning. It might be better to assume that the application that uses pmemkv as a library doesn't always have rights to create a persistent pool, so the size parameter goes away, and we'd instead rely on pmempool in documentation and makefiles to create persistent pools with appropriate sizes. Allowing pmemkv to create pools directly made for a convenient starting point, but that might commute application and administration rights more than we'd like, especially if we can automate use of pmempool so that the normal developer experience is not degraded.

Removing the size parameter affects all language bindings. I'd assume that we'd also remove the kvtree_size API, since the primary use for this has been in automated testing to validate that the size parameter is working correctly. How pmemkv signals out-of-space conditions up to application code is not affected by removing the size parameter.

We could also have pmemkv put out a warning when it detects use of filesystem DAX, to warn users of the danger of running in this configuration in production. There is obvious danger here that users will follow directions to configure "DAX" (without realizing the differences between the varieties of DAX) and end up in a configuration that is not power-fail safe, and not realize their mistake until after a failure.

[RobDickinson]

Going to stick with existing workflows for now -- requiring use of pmempool for all use-cases might be arguably better in some ways, but to do across the board is added rework and extra steps.