Add optional 'extensions' entry to errors

[IvanGoncharov]

As discussed on the last WG meetup it makes sense to define some common error properties like: code, category, etc. I think such initiative should be lead by public API owners and required broader discussion.

However, I think we could make this process more painless by proactively preventing possible name clashes.
For example, if a future version of spec will defines code as a string it can break some public API that use integers for error codes.

Another alternative would be to recommend prefixing additional fields with x- (e.g. x-code) but I think it's better to reuse extensions from response object.

[leebyron]

Made some edits, but this is definitely a straight forward improvement. Thanks for drafting this after the WG meeting!