Introducing GivenUUIDGenerator

This PR needs PR #32 to be merged first (just to make 063353d works)

Purpose of this PR is multiple :
- Refactored UUIDGenerator in order to make it a @Component instead of a ThreadLocal instance
- This way, the @Component could be replaced at runtime (for instance, to enable uuid generation playback mode). 
- Provided some utility methods allowing to add a temporary Machine adding a top-priority replacement for a named component, then cleaning it. Will need your feedback about what I've done, I think it could be improved in terms of simplicity.
- @Component with different `Name` will be provided each time an overridable generator will be used in codebase (identified `RestxError` & `SessionResource`)
- Provided `GivenUUIDGenerator` which allows to enable playback mode during a spec test, on a given component's name. Usage will look like this :

  ```
title: should authentication be successful with existing user
given:
  - time: 2013-08-16T16:38:36.549+02:00
  - uuidsFor: SessionUUIDGenerator
      data: [ "e71a0f9f-9082-4626-bc34-3893c540566d" ]
wts:
  - when: |
        POST sessions
        { "principal": { "name": "admin", "passwordHash": "1d528266b85cf052e9a4794803a57288", "rememberMe": "true" } }
      then: |
        200
        { "key": "e71a0f9f-9082-4626-bc34-3893c540566d", "principal": { "name": "admin" } }
  ```

ATM, I'm relying on some sort of "hack" to share machine between client (tests) and server (restx) : using a named context-local machine with a hardcoded name.
It implies the server `Factory` reads inside this context while looking for UUIDGenerator ... which is not something "obvious" (I provided helper methods to facilitate this, but nobody is forced to use them)
We could largely improve this by implementing some sort of "session affinity" between client (tests) and server (restx), but it will be the topic of another issue.