i18n support

depends on #353

Please review

simple i18n framework

I'll provide justification for this in a bit.

The ext-fr.js style of localization files have a couple shortcomings in my opinion: 1) they require a build time decision about the language (instead of using a client's runtime settings), and 2) they include a fair bit of logic that translators shouldn't have to worry about (if this, apply that).

I think a simple i18n framework could be put together with the following goals:

1. Support runtime preferences where possible (browser language settings), allowing a single build to include translations for multiple languages.
2. Make language files as simple as possible for translators to work with.
3. Allow applications (or the library in the future) to support setting the language after initialization (or initial library load).

The attached patch accomplishes these goals without adding a lot of overhead (in my opinion). The GeoExt.Lang object is an observable singleton. The add method takes a language tag (of the rfc3066 form) and a lookup object. The lookup object has a member for each object in the application with localizable strings. The member name is a dot delimited string that resolves to the target object (e.g. "GeoExt.MapPanel.prototype") and the member value is an object that should be applied to the target object to localize string properties. The add method can be called multiple times to compile the dictionary for a given language. The set method actually sets localizable strings on target objects based on entries in the dictionary. Setting to a language with a subtag (e.g. "en-CA") first applies all strings from the primary tag (e.g. "en") before applying any subtag strings. This allows for partial or absent regional dictionaries where the primary language settings will still be applied.

When the library loads, the browser language settings are set as the default locale. This means that dictionaries for multiple locations can be included in a single build and the user should get strings based on their local language settings. If the app developer wants to set a single language (regardless of user settings), they call set after add.

Tests demonstrate a few examples of use.

fix a syntax error in GeoExt-fr.js and add requires GeoExt/Lang.js

Looks good. Thumbs up - please commit.

(In [2486]) Adding simple i18n framework to facilitate localization of applications. Thanks fredj for the French strings. r=ahocevar (closes #352)

(In [2487]) Adding French strings from fredj for the ux (see #352).