Phar distribution archive, distribution improvements

[evought]

As a follow-on to #32, continue to improve the distribution process and archive:

• Attempt to uncover any evolving standard for library Phar archives or for un-bundled distribution archives generally and document it. Document findings in some fashion.
• If there is no current or evolving standard, come up with something reasonable, document it, promote it, and move this package in that direction.

Goals of distribution archive:

• Package for ready distribution of production-materials rather than developer materials (e.g. artifacts such as API docs, sample code, not unit tests).
• Make it relatively easy for developers of platform-packages (e.g. RPMs) to track and unbundle dependencies according to their requirements. Our goal is not to make a platform package but simply render our package (or a client-application we are included in) subject to scriptable repackaging in a sensible manner.
• Preserve Composer metadata.
• Our package, whether installed via Composer or a distribution package, should be easy to incorporate in the client app, inject dependencies, and configure, particularly:

1. If the database components are not used, they should have no effect on the client application, and

2. If the database components are being used, it should be possible to configure/install the schema and queries in the client app, including alongside other database functions, cleanly.

3. Any dependency-injection we use to accomplish this should be light-weight and not end up simply tightly-coupling a configuration system in order to avoid tightly-coupling the configuration values.

Item (1) above argues for the possibility of putting VCardDB into its own packaged sub-component in the future, possibly in a 1.1 to 2.0 time-frame.

Deliverables For This Issue:

A) Document such existing practice as can be discovered.

B) Document a direction for packaging of this component and, preferably, which may be reused for future projects.

C) Make concrete steps towards implementing that decision, laying out a path for future progress.

As this issue has ended up being much more complex than expected, it is not expected to be solved in the time-frame of this issue. Package should be usable in the 1.0 time-frame but is expected to have warts.