Update package.json to v0.2.9 in preparation for urgent bug fixes.
... I've regressed base component contruction contract for some variants of onm data model semantic bindings in v0.2.8.
This is to be fixed in 0.2.9 and supported by additional deep tests of component creation. Recent enhancements to onm.Store.createComponent are to blame for this regression. That, and inadequate base test coverage.
Work in progress: start of deep white box testing, and bug fixes on...

... the recently revised and parenthetically broken-in-v0.2.8 onm.Store.createComponent code path. At issue is a tricky set of policy routines that negotiate the creation, override of onm data component keys. I'm here looking at this again because of a regression caught several layers above onm in the Encapsule SCDL stack: one of over five hundred passing tests was failing because of unset / incorrectly set component keys. Really that error never should have escaped onm's own test suite. So I'm starting with onm.Model intrinsic semantic binding implementations and working through them carefully with white box tests. Once those work and are supported by tests, I will re-examine the SCDL data model's semantic binding function implementations and make necessary corrections if necessary.
Additional tests to confirm the intregrity of component keys under...
... different component creation conditions.
Update tests of built-in component key generator...
... this commit uses programmatically-generated Mocha tests in a trivial way. However, the basic pattern demonstrated is quite powerful. I'm going to extend to author some generic data model acceptance tests to be used to verify the consistency of property declarations/semantic binding function implementations (external and onm-built-in-internal implementations).
Snapshot of work in progress on dynamic Mocha tests...

Most of the action here in in the new file ./test/fixture/test-shared-onmd-generic-suite.js that implements a data-model-declaration-driven dynamic Mocha test suite used internally to validate onm's own test fixture data models, and to be used by onm-derived modules to similarly verify base-level validity of onm data model declarations.

There are several areas that need to be improved:
- Infrastructure: this style of building dynamic Mocha test suites seems to be working fairly well. And it scales nicely (with a few carefully-placed closure scopes). However, there's a problem with the error reporting I've observed in the dynamic tests where any failure in the dynamically added vectors seems to terminate the report. Luckily totals are reported so I see no evidence that Mocha will falsely pass the entire suite. So, no stage-for-deploy of known-bad images. But, there's that reporting thing...

- onm data model generic suite coverage: not done yet. The generic suite will be further expanded to include verification of all defined component create/remove, verification of property construction in each namespace...
Disable the unmaintained earlier dynamic test suite attempts.
Fix what I think (hope) is the last of the key integrity...
... problems I introduced with 2.6+ onm.Store.createComponent code path changes. Note that there's still a top-level failing test (expected). I will patch the expected JSON to correct shortly.
onm v0.3.0 RC1...