Cross Origin Resource Sharing for OpenSRF

Background
----------
Browsers' same-origin policy currently restricts requests to the current website's domain to prevent various nefarious scenarios. However, because APIs and other web resources need to remain open to cross-site use Cross Origin Resource Sharing (CORS) was created to allow services to formally authorize cross-origin requests. CORS makes it simple to use OpenSRF's HTTP translator and gateway APIs on websites using seperate domains.

Example Scenarios
-----------------
1) A library would like an AJAX-driven "quicksearch" box on their main site, which is hosted on a different domain than their catalog.
2) A developer wants to create new web applications and services that tie into Evergreen, but does not wish to install EG locally or configure a proxy.

Implementation
--------------
The function crossOriginHeaders() has been added to apachetools.c. Incoming requests are checked to see if they have an Origin header. The value of the Origin header is checked against a whitelist defined in opensrf_core.xml config (XPath: /config/gateway/cross_origin/origin) The function returns 1 if CORS headers have been added to the response.

Notes
-----
* The OpenSRF Javascript client library (opensrf.js) defaults to the root of the current web host "/osrf-http-translator." In addition, synchronous requests are presumed in some situations: resulting in the oncomplete method never returning (Blocking requests are not possible with cross domain XHR.)
* It is also possible to enable CORS with the Apache "set header" configuration directive. However, this means that the necessary headers would be appended to every response.

Links
-----
Specification - http://www.w3.org/TR/cors/
Wikipedia Article - http://en.wikipedia.org/wiki/Cross-origin_resource_sharing

Signed-off-by: Bennett Goble <nivardus@gmail.com>