Consolidate parsing exceptions

Our XContent parsing code currently produces a mixture of XContentParserException, ParsingException and ElasticsearchParseException. Having three different parse exception implementations seems confusing and trappy, so we should make some effort to consolidate them.

XContentParserException is produced by ObjectMapper and friends, and lives in the x-content module. It produces error messages that include line and column numbers, and is handled nicely when it bubbles back up to the REST layer (produces reasonably formatted messages with correct root cause, and returns a 400 BAD REQUEST). It was introduced specifically as part of the effort to move x-content into its own module.

ParsingException lives in server, and extends ElasticsearchException. It includes line and column numbers as metadata but does not include them by default in its output message. As an extension of ElasticsearchException it also has Writeable methods, which as far as I can tell are never used because XContent parsing is always done on the co-ordinating node. It was originally a QueryParseException but then expanded to cover more parsing.

ElasticsearchParseException is a simple extension of ElasticsearchException that always returns 400 BAD REQUEST. It was introduced in the initial commit.

XContentParserException seems to cover pretty much everything we need, so my suggestion is that we remove ParsingException and ElasticsearchParseException and use XContentParseException everywhere instead.