Extend error response with additional information

[Hazel-Datastax]

What this PR does:
Extend error response with additional information
The matching family and scope for each error code are here

Which issue(s) this PR fixes:
Fixes NA

Checklist

• Changes manually tested
• Automated Tests added/updated
• Documentation added/updated
• CLA Signed: DataStax CLA

[Hazel-Datastax]

If the extendError flag is enabled, the new error response will be like:

{
    "errors": [
        {
            "message": "\"insertOne1\" not one of \"CollectionCommand\"s: known commands are [countDocuments, deleteMany, deleteOne, estimatedDocumentCount, find, findOne, findOneAndDelete, findOneAndReplace, findOneAndUpdate, insertMany, insertOne, updateMany, updateOne]",
            "errorCode": "COMMAND_UNKNOWN",
            "scope": "",
            "id": "18819834-b12d-4395-b484-f6795c2467cc",
            "title": "Provided command unknown",
            "family": "REQUEST"
        }
    ]
}

By default, the flag is disabled, and the error response will not be changed:

{
    "errors": [
        {
            "message": "Provided command unknown: \"insertOne1\" not one of \"CollectionCommand\"s: known commands are [countDocuments, deleteMany, deleteOne, estimatedDocumentCount, find, findOne, findOneAndDelete, findOneAndReplace, findOneAndUpdate, insertMany, insertOne, updateMany, updateOne]",
            "errorCode": "COMMAND_UNKNOWN"
        }
    ]
}

[tatu-at-datastax]

Not sure why this was changed? Earlier code more robust wrt changes to error message.

[Hazel-Datastax]

Because I added extendError - the configuration in the ErrorCode class. It will cause the class initialization error in this case - because it cannot find the config

[tatu-at-datastax]

Ok. We will probably change things to ensure that no loading occurs from within static initialization of ErrorCode (or its replacement) in future.
But is fine for now.

[amorton]

couple of changes ot the way we are creating the family / scope - but I am still happy with the general approach rather than changing all of the existing ErrorCode enum

[vkarpov15]

Should there also be an error scope for OPTIONS if you pass in an invalid option?