Implement "direct NVDIMM" mode bypassing LVM

[okartau]

Driver could be made capable to operate in 2 modes:

1. LVM-enabled mode (current main mode being developed)
2. Direct-NVDIMM mode (was one of prototype models before LVM mode was added)
   Direct-NVDIMM code stubs have been kept in code just in case if we decide to keep that path.
   In that mode, driver will create NVDIMM namespaces and provision block devices based on those, directly.

Cons of direct mode:

• leaves fragmentation risk wide open

Pros of direct mode:

• LVM layer is bypassed, i.e. less possible error paths, (see Clean handling of driver restart #25), simplified start-up
• runtime dependency on LVM components will not be needed
• Performance hit by LVM avoided (hit is not expected anywhere close to serious though)
• namespacemode (see We need an option to create a BTT enabled namespace #22, Implications of LV mode #30) can be set per-volume which is not possible in LVM-mode

We could say in doc: select LVM mode if you are concerned about fragmentation (dynamic create/delete of different volume sizes expected), but you can select direct-nvdimm mode if you only allocate once i.e. fragmented states are not expected.

[okartau]

direct-NVDIMM mode implementation path became a much more cleaner with recent architecture change by #46

[okartau]

Progress report: After few minor recent fixes/enhancements (like #114), simple unified-mode lifecycle (as in util/lifecycle-unified.sh) can be run both on emulated NVDIMM and in HW-based pmem, when driver runs in "ndctl" driver mode (i.e. bypassing LVM2)

[okartau]

Progress report: util/sanity-unified.sh fails on both emulated-pmem and on HW-pmem same way, so we cant blame qemu this time. I will create separate issue to keep things isolated

[okartau]

resolved via merge of direct-nvdimm mode in #133