Simplify Enum support (beta idea)

[rodionmoiseev]

Inspired by @lelmarir Automated Enum binding with Guice commit.

Motivation

Currently providing locale sensitive translations for Enums is relatively complex. In overview it requires 2 steps:

1. Create a separate c10n-interface with translations
2. Install an "enumMapping" filter for the Enum in question

The biggest problems with this approach are:

• Enum mapping cannot be checked at compile time, and thus is a pretty fragile mechanism. This also kind of goes against the compile-time safety of C10N.
• Additional interface needs to be maintained for mapping only, which is boilerplaty and some static code inspection tools may not like it.
• Translations are currently fetched by the filter, which is executed every time a c10n interface method is invoked, meaning more overhead.
• Each new enum mapping needs to be explicitly installed during C10N configuration time, making maintenance more difficult

A Better Approach

Being able to specify translations directly on the values of the Enum seems to do the job better:

enum Pet {
    @En("Cat")
    @Ru("Кот")
    CAT,

    @En("Dog")
    @Ru("Собака")
    DOG
}

Enum-type arguments can be retrieved and cached at c10n initialization time, in the same way other standard translations are fetched, instead of c10n interface method invocation time.

This approach would make Enum support more transparent, with no extra configuration, and with less overhead.

It would also work transparently with other c10n extensions, such as external/internal resource loading, Guice support and Logging tool.

[lelmarir]

Being able to specify translations directly on the values of the Enum

don't really like this, it is not always possible to directly modify the enum to add locale annotations, and beside a separate PetMessages seems a more clean approach