Different RestxSession cookie names for different apps & Optional injectable components support

When developping several restx application (thus, working on `localhost` domain), restx cookies are interfering since their names are the same.
Moreover, it would be nice to be able to change the `RestxSession` & `RestxSessionSignature` cookie names if the restx user doesn't want to tell its consumer that the serverside technology is based on restx.

Proposition here, is to define :
- An `app.name` @Named String, not set by default (to keep backward compatibility), allowing to suffix restx session cookie name with an app name. Thus, you will be able to work on different apps locally, which will have specific cookie names for the `localhost` domain name.
- A RestxSessionCookieDescriptor component, intended to welcome generated cookie names, @Provided by default in `SecurityFactory` with following values :
-- `RestxSession` & `RestxSessionSignature` if `app.name` @Named String has not been defined (this will keep bacward compatibility)
-- `RestxSession-${app.name}` & `RestxSessionSignature-${app.name}` is `app.name` @Named String has been defined
Obviously, this behaviour can be overriden at the user convenience.

Note that if merged, you will need to update the [Generated app explained](http://restx.io/docs/generated-app-explained.html) documentation page, in order to talk about the `app.name` @Named String.

EDIT : Updated current pull request with another feature which was needed prior to the RestxSession cookie name generation : handling `Optional` injectable components.
That is to say, if a @Provide method signature is looking like this :
```
@Provides
public Foo foo(Optional<Bar> bar) {
}
```
The Bar resolved component will be injected only if found. Otherwise, the Optional.absent() value will be provided.
This will obviously work on @Named components too.
Note that as soon as you're relying on an Optional component, you :
- Will need to provide a Generic to the Optional used (otherwise, you will have a compile-time error)
- Won't have any component existence check (since you explicitely said you're not *hardly* relying on the bar component)