Add PseudoConstants to Schema Metadata

Problem: Our field option lists (aka pseudoconstants) are not retrievable programmatically. This problem has 2 parts:

1) Pseudoconsants are not linked to fields in our schema. For example, to retrieve the option list for the field civicrm_contact.preferred_communication_method you must know that the name of the pseudoconstant is "pcm" (and you must also know which pseudoconstant class it is in). This should not be needed.

2) Fetching certain option lists involves some logic. For example, the list of contact subtypes needs to be filtered by contact type. The list of states needs to be filtered by selected country, etc. In our current model you must know in advance what logic may be needed for each option list and pass the appropriate params to the psedoconstant function (and each function takes slightly different params!).

To address these problems we have restructured the use of option lists in the following ways:

1) All fields with option lists now declare that info in the schema metadata.
2) We have added a single entrypoint for retrieving option lists that takes contextual params and can build logic around that context.
3) We have deprecated some pseudoconstant functions and removed others. In general we are deprecating the direct access of pseudoconstant classes (note this means the "constant" api is also now deprecated in favor of api.entity.getoptions).

Example to fetch simple options:
CRM_Contact_BAO_Contact::buildOptions('gender_id');
or
civicrm_api('contact', 'getoptions', array('field' => 'gender_id'));

Note: the api.entity.getoptions now wraps around BAO_*::buildOptions rather than the ad-hoc guesswork it's been doing up till now.

More complete example:
$fieldName = 'contact_sub_type';
$context = 'edit';
$entity = array( // pass in all known fields about this contact - gender_id, first_name, last_name, etc. and most noteworthy for this example: contact_type
);
$options = CRM_Contact_BAO_Contact::buildOptions($fieldName, $context, $entity);
// $options will contain sub-types filtered appropriately by contact type

The upshot of this is that (in combination with some other metadata additions like widget) it will be possible to render a form/view/search for any entity without knowing anything specific about that entity or anything specific about any of the fields. All this info can be fetched from the metadata, and logic related to building contextually appropriate option lists is handled by the BAO.