REST API - Initial Implementation

This is the initial version of the REST API, #3175. It is still very experimental but ready for feedback and testing. Please do not merge this quite yet, as there's likely to be quite a bit of changes required before it's ready.

Authentication is handled two ways. First, if Force Checkout SSL is enabled, the API index declares support for SSL and API requests can be easily authenticated by passing the consumer key and secret key as HTTP Basic Auth username/password.

If SSL is not available, API requests must be signed according to the [OAuth 1.0a spec](http://tools.ietf.org/html/rfc5849), implemented as ["one-legged" OAuth](http://oauthbible.com/#oauth-10a-one-legged). This means that every request is signed and authenticated instead of the consumer receiving a token for future use. While it's somewhat of a pain to implement, it's the *only* way to ensure requests are secure when using plain HTTP.

To test/review, pull this branch and comment out or remove [this filter](https://github.com/maxrice/woocommerce/blob/api-dev/includes/api/class-wc-api-authentication.php#L24) so you don't have to authenticate. All endpoints are at `http://example.com/wc-api/v1/`. I'll update this list of endpoints as implementations are finished.

__Index__
`GET /`

__Orders__
`GET /orders`
`GET /orders/count`
`GET /orders/<id>`
`GET /orders/<id>/notes`
`DELETE /orders/<id>`

__Coupons__
`GET /coupons`
`GET /coupons/count`
`GET /coupons/<id>`
`GET /coupons/code/<code>`
`DELETE /coupons/<id>`

__Customers__
`GET /customers`
`GET /customers/count`
`GET /customers/<id>`
`GET /customers/<id>/orders`
`DELETE /customers/<id>`

__Products__
`GET /products`
`GET /products/count`
`GET /products/<id>`
`GET /products/<id>/reviews`

__Reports__
`GET /reports`
`GET /reports/sales`

## Open Questions
* Should we rename legacy `wc-api` endpoint to `wc-ipn` to prevent confusion with REST API?
* Since the v1 API won't support creating products or orders, should the `DELETE` method be removed for those endpoints as well?
* Should responses be consistent with use of a blank string or `null` for non-values? currently it's a mix
* What is the proper permission check for count methods? e.g. `GET /orders/count`

## Closed questions
* ~~This uses some code from the [WP API](https://github.com/WP-API/WP-API) project, mainly the [WP-JSON-Server class](https://github.com/WP-API/WP-API/blob/master/lib/class-wp-json-server.php). It makes routing and other response-related stuff outrageously easy. My only issue is that it couples a JSON response type very tightly to the routing, which makes it impossible for us to support XML-based responses.~~
*~~I think the routing handling could be refactored into a base class, and two sub-classes created, one to handle JSON and the other to handle XML. This would also make it easier to make the entire class more WooCommerce-specific, which prevents any unexpected conflicts if a user is running the WP-API as a plugin on their server, or if it's merged into WP core.~~
* ~~How should order/coupon/product/customer meta be implemented?I like the idea of a `meta` attribute for each of the response objects that can be enabled with something like `?include_meta=true` or similar in the request.~~ __will be implemented as resource-specific `product_meta` attributes. Clients will indicate they want meta returned in response by including `meta=true` in `filter` parameter.__
* ~~Should [get_json_url()](https://github.com/maxrice/woocommerce/blob/api-dev/includes/wc-core-functions.php#L349) and [json_url()](https://github.com/maxrice/woocommerce/blob/api-dev/includes/wc-core-functions.php#L365) be prefixed?~~ __yes and refactored to return canonical WC-API URL.__
* ~~Global functions to create orders/products would be very helpful in reducing code duplication. Order/Product clones of [woocommerce_create_new_customer](https://github.com/maxrice/woocommerce/blob/api-dev/includes/wc-customer-functions.php#L42) would be perfect~~ __creating orders and products via the API will be pushed to WC 2.2__
* ~~`/orders` returns orders with any status by default, should default be processing/completed instead?~~ __orders will include any status by default__
* ~~should totals be cast to string so they're string quoted in json response?~~ __totals will be cast as string__
- ~~When requesting a variation ID, should the response include *only* the variation product? or should it include the variable parent product, and the requested variation listed as the only variation?~~ __variations will return the same set of data as a regular product, with the parent variable product data included as a top-level attribute.__
* ~~Should the `/coupons` endpoint have a custom parameter for getting coupons by coupon code? The `q` parameter searches both code/description already~~ __a new endpoint will be added__
* ~~API keys are currently 1 per user (and API requests run under the WP permissions of that user), should we support multiple keys per user?~~ __API keys will be serialized into a single user meta entry to support multiple keys__
* ~~should API secret keys be hashed prior to storage? This would prevent accessing the plaintext key again after it's displayed + stored~~ __secret keys cannot be hashed because we need them in plaintext to calculate the OAuth signature for plain HTTP requests__
* ~~We need to require WP 3.7 in order to allow date filtering, any obvious problems with this? It degrades gracefully for pre-3.7 versions~~ __WC 2.1 will bump the minimum WP version required to 3.7__

## Todos

### General
- [x] Refactor WP_JSON_Server to WC-specific API server to handle JSON and XML, completed in SHA: https://github.com/maxrice/woocommerce/commit/ed6de29bfc96b091d551391f7563fba75fd19226
- [x] Add store-specific information to API index, like currency, base location, etc, completed in SHA: https://github.com/maxrice/woocommerce/commit/ed6de29bfc96b091d551391f7563fba75fd19226
- [x] Permission checks for reading/editing/deleting (via resource-specifc helper methods with `current_user_can` checks)
- [x] Date standardization for requests/responses (completed in SHA: https://github.com/maxrice/woocommerce/commit/87ff36db123136b1ada111798e4a8e7781111551)
- [x] `filter_response_fields()` method should support specifying sub-fields, e.g. billing_address.country (completed in SHA: https://github.com/maxrice/woocommerce/commit/31303693251b411d641e9aa0d8d129b431a41018)
- [x] Refactor ID checks into base class method (completed in SHA: a13a95e452f1836c6acf689936b1a86cff4245b6)
- [x] Refactor resource method names to snake_case (completed in SHA: a13a95e452f1836c6acf689936b1a86cff4245b6)
- [x] Improve Navigational/Total count response headers (completed in SHA: https://github.com/maxrice/woocommerce/commit/490dc758a97cfd84fbcae4987dbb21b290a95c2c)
- [x] Scope filter params like `q`, `limit`, `offset` and date filters behind brackets, like `GET /orders?filter[q]=search` (completed in SHA: a13a95e452f1836c6acf689936b1a86cff4245b6)
- [x] Allow clients to specify the requests should include meta by adding to the `filter` parameter, like `GET /orders?filter[meta]=true` (completed in SHA: https://github.com/maxrice/woocommerce/commit/48e8363db04aba9c9d30163b9781ac58b8e4d72a)

### Products
- [x] Implement `GET` method (completed in SHA: https://github.com/maxrice/woocommerce/commit/674ea420123cde15395760febfb3ae6fd2ad6e4b)

### Customers
- [x] Support `created_at_min`/`created_at_max` with `pre_user_query filter `using [this](http://wordpress.stackexchange.com/questions/51485/how-can-i-query-all-users-who-registered-today) (completed in SHA: https://github.com/maxrice/woocommerce/commit/1f5db980468738ff6d5082ab31035059ff63b820)
- [x] Implement pagination (completed in SHA: https://github.com/maxrice/woocommerce/commit/490dc758a97cfd84fbcae4987dbb21b290a95c2c)
- [x] DRY valid user checking code (completed in SHA: https://github.com/maxrice/woocommerce/commit/a13a95e452f1836c6acf689936b1a86cff4245b6)

### Coupons
- [x] Implement `GET /coupons/code/foo` endpoint (started in SHA: https://github.com/maxrice/woocommerce/commit/a13a95e452f1836c6acf689936b1a86cff4245b6, completed in SHA: https://github.com/maxrice/woocommerce/commit/5ab8e085ad3aefb912676738dda1fed234a23ec3)

### Reports
- [x] Implement `GET` for Sales Report method (completed in SHA: https://github.com/maxrice/woocommerce/commit/c1854b26b946d9ca7e01ddd9f7cad4176bd84422)

### Authentication
- [x] Implement API-key based read/write permissions (completed in SHA: https://github.com/maxrice/woocommerce/commit/ef22f032750682f1520350c05cc5a184ec789d3a)

### Settings
- [x] Hook up settings to authentication class (completed in SHA: https://github.com/maxrice/woocommerce/commit/61fb0f760a8672b58780ed5b16b41501d1c42aff)
- [x] Implement key management (completed in SHA: https://github.com/maxrice/woocommerce/commit/f542ce87a16150062025600501f279476eb66760)

### TBD (in order of importance)
1. Implement API request logging - probably a new tab in Reports
2. Orders - Implement `PUT` method, particularly for updating status of an order
3. Customers - Implement `POST` and `PUT` methods
4. Coupons - Implement `POST` and `PUT` methods
5. Implement XML parsing/generation
6. Products - Maybe implement `PUT` method
7. Allow un-authenticated access to `GET /products` - this needs to be *very* carefully tested to make sure we don't accidentally expose sensitive information. We might even consider an entirely new endpoint so it can be sandboxed.
8. Consider allowing multiple API keys per user, probably don't need to bother since it's easy enough just to create a new WP user and assign keys that way.

### Documentation
* Will be added to docs.woothemes.com
* Creating signatures, see [good OAuth 1.0 reference](https://dev.twitter.com/docs/auth/creating-signature)
* Creating nonces, see [reference](https://dev.twitter.com/discussions/12445)
* Sample code