Add section for error handling

[sebastien-rosset]

This PR adds a section about error handling.

The following statement is written twice inside the Function Evaluation section:

How and when this error is raised is implementation specific

IMHO, this statement applies to all error handling scenarios. So instead of making that statement specific to function evaluation, it could be moved to the section about error handling.

The spec has 34 occurrences of the word "error", but it does not really codify how errors are raised.
The spec does not have a list of error types and it does not have guidelines about when to use these error types.

[springcomp]

Please, include not-a-number and unknown-function (on the top of my head).

[springcomp]

@sebastien-rosset thanks for your contribution.

I think this is a good opportunity to address error type precedence in this PR.

Also, any changes to the spec should ideally be tracked into a JEP – only for historical purposes.
You can try submitting a discussion / JEP to this repo ? If you feel comfortable, we are happy to discuss this in JMESPath Community as well.

Would you mind starting a JEP document in the discussions for that? You can find some samples of past discussions tagged with jep-candidate there as well.

The numbering would be defined later on.

[jamesls]

The compliance tests repo defines these error types so I'm fine merging as is. The compliance tests also define a syntax error type, but I don't think we need that as it's implied by the grammar that anything that doesn't parse properly raises a syntax error.

Thanks again for the contribution!

[jamesls]

Rebased/merged in 28fd853