Fix #73 : Deal with cardinality v. logical values in PropertySpecification
* Created a field plus static and instance methods to access information about
the cardinality of a PropertySpecification. Intentionally made the new values
strings to avoid confusion with int constants.
* Changed constructor.
* Updated specification registry.
* Changed the names of the existing multiplicity predicates and constants to
make it more clear that they deal with property instances (multiplicity)
rather than logical values (cardinality).
* Added documentation explaining the difference.
* Made updates throughout system to incorporate changes. Due to separation of
these concepts, several existing proeprties became MULTIPLE_PROPERTY which in
turn changed what __get was returning and what assignment was expecting.
* Additional tests. While adjusting testcases, caught and fixed several
miscellaneous defects. Cleaned up test code.
* Cleaned up setFNAppropriately based on the fact that FN is now
MULTIPLE_PROEPRTY and I no longer have to arbitrarily choose an N or ORG
record to set from if there are more than one. Noted that this code should
copy LANGUAGE and ALTID parameters from N and ORG once those are implemented.
* Removed N hack from VCardDB as required in issue report.
* Added doc comment and type hint for VCard::builder.
Refactored PropertyBuilder::push(VCard) to pushTo(VCard) in order to reduce
possible confusion with VCard::push() and clearly indicate direction of flow.
Added a simple dotable script file to add the Composer dependencies
(e.g. phpunit) to path.
Corrected error check for PREF to use cardinality rather than multiplicity.
Fix #74 : COMMA Properties.
COMMA_VALUE properties such as categories now being parsed again, creating
multiple Property instances. Added testcase to prevent regression.