- Implement 107 wrapper (issue #70)

Okay let's start this review, see how far we get. Will be very surprised if there are *not* iterations on this.
Once we start picking apart pieces of it as well I can make some smaller commits that isolate the changes

Notes:
- Implements the 107 API
- includes Louis' changes for issue #21
- Passes the TCK but there are many other tests needed:
  - unit tests of a good deal of the 107 module code and things the TCK doesn't cover
  - tests for changes made in ehcache proper
- `Store` has new variants of computeXXX() methods that control what happens when the compute function returns the same thing as the existing value in the store
- Ehcache `Expiry` now has a method for update vs. create. 
- There's a relatively hacky class `Jsr107Cache` that exposes cache operations unique or with different semantics that ehcache
- There is no integration with `ResilienceStrategy` for the cache ops that are unique to 107
- Some stats changes:
  - cache "hits" registered for conditional ops that fail, but for which the key was present
  - same thing for "misses" when conditional ops fail b/c the key doesn't exist
- removed the clear() methods from our statistics classes. That is a 107 only thing now



Alex and chatted about this a bit, and we think the following proposal makes sense:

The default URI for Ehcache 107 cache managers is: `ehcache://default`.  This URI isn't actually resolvable by a user, but we understand what it means.  The "default" default config is an empty configuration, this is however overridable with a property (either a system property, or one passed to the provider).  Setting say `ehcache.config.default` to an explicit config (in some form) makes that config resolve when ehcache://default is used.  Forms for that config object could include: a URI object, a string URI, a config object, an xml string etc.

Does this make sense?