Refactor KNOWN_LANGUAGES into {DEV,PROD}_LANGUAGES

[stasm]

Remove KNOWN_LANGUAGES in favor of DEV_LANGUAGES and PROD_LANGUAGES
which are lazily used in LANGUAGES_URL_MAP and LANGUAGES depending on
the value of DEV.

DEV_LANGUAGES are autogenerated from the contents of the locale/
directory in the root of the project.

PROD_LANGUAGES should be maintained manually.

In addition, the commit removes the RTL_LANGUAGES setting which wasn't
used anywhere. Django's default value for LANGUAGES_BIDI is sufficient
and used by django.utils.translation.get_language_bidi.

[jbalogh]

I don't know the story behind this, but it doesn't sound like a good idea. Having a significant difference like this between dev and prod is going to cause problems because people will see everything working fine in dev.

[stasm]

The thinking behind this is that we'd like to allow the localizers to test their translations early on on dev. OTOH, we don't want all locales to be switched on on prod; localizers need to sign off on the translation once they feel good about it, and only when they do is their locale added to PROD_LANGUAGES.

[fwenzel]

@jbalogh: This is true, but with the three instances of an app (dev, stage, prod), the stage instance will mimic what prod is going to have with the next push. So If all is well on stage, it will be on prod.