Issue #222: formal API support

* Catch api/* urls
* api/v1/foo/bar/... urls are parsed as an API call containing parameters. Extra parameters can be added as GET ones.
* new API class to manage API requests. 4 API services implemented:
    - entity: Return all translations for an entiry (equivalent to /string/ Json API)
    - locales: Return the list of locales for a repository
    - search: Search on repositories (equivalent to current Json API on main page for strings and entities)
    - tm: Translation memory, similar to the Amagama service
* API public methods (none static):
    - getParameters()
    - getExtraParameters()
    - getService()
    - isValidRequest()
* New Project class to make key data available everywhere in the application without using globals
* Project public methods (all static):
    - getRepositories()
    - getRepositoriesNames()
    - getGaiaRepositories()
    - getDesktopRepositories()
    - getRepositoryLocales()
    - getReferenceLocale()
* Updated Strings class with these static methods:
    - levenshtein()
    - levenshteinQuality()
* Refactored all search views to be MVC and separate data generation from presentation (needed to redirect JSON API calls to new v1 API services)
* API changes:
    - Entity service returns an empty json array for invalid entities + filters out {ok} strings for mozilla.org
    - The "Strings and entities" json source is no longer supported
* Tests for all public methods
Personally I don't think so. For sure right now the dropdown list looks quite bad (on Mac it reads "www.mozilla" when selected), we'll need to fix it if/when we add longer labels.