Added the JSONHTTPException to the exceptions.py file

The exceptions module was removed from the latest version of Flask
(0.9) and since it was added in the same version, it doesn't show up
in any earlier versions. This means that Flask-Restless is broken for
all versions of Flask. This commit adds the JSONHTTPResponse from the
removed exceptions module in Flask to the exceptions module in
Flask-Restless. The commit where the exceptions module was removed can
be seen here:
https://github.com/mitsuhiko/flask/commit/4c27f7a8c4bbe6621681178be716e6270067a3ad.
Fixed `__repr__` functions to work with Python 2.6 and above

In a Python 2.6 repl an exception is thrown when viewing instances of
the Filter, SearchParameters, and OrderyBy classes. This is because
the call to `str.format` in the `__repr__` method of each omits the
indexes for the arguments, which is a feature added in Python 2.7.

From the Python docs [7.1.3. Format String Syntax][1], "Changed in
version 2.7: The positional argument specifiers can be omitted, so '{}
{}' is equivalent to '{0} {1}'."

[1]: http://docs.python.org/2/library/string.html#format-string-syntax
Removed a dependency on the Flask app from create_api_blueprint

The create_api_blueprint calls _next_blueprint_name which, in turn,
checks all blueprints on the Flask app object to see if any previously
registered blueprints have a matching name and, if so, it returns a
new name with a suffixed index. This creates a dependency on the app
object in the create_api_blueprint method. This can cause problems in
situations where the developer wishes to move the creation of the API
endpoints into a module separate from the one in which the app object
is created. Allowing the user to create blueprints for API endpoints
in a separate module without the need to import the app object is key
in preventing a circular dependency between modules.

Since creating an API blueprint is more of a "power user" function, it
stands to reason that making sure the name of the blueprint does not
overlap other registered blueprints should be a responsibility of the
developer. For this reason, I've moved the call to
_next_blueprint_name out of the create_api_blueprint method and into
the create_api method. In the latter case, things are a bit more
automated and the case for renaming blueprints is a little stronger
there.
Merge branch 'remove-app-dependency-in-create-api-blueprint'
Merge branch 'python2.6-fix'