Refactor errors, adding section for Message Function Errors

[eemeli]

CC @mradbourne, who should be added to the repo.

As discussed yesterday, our error categories could be improved. This PR effects the categorisation we discussed, with "Message Function Error" introduced as the supertype of the errors that are coming from a custom function and "Invalid Expression" renamed to avoid its re-definition of what "valid" means in an MF2 context.

This and #767 should not be considered as blockers for each other. Instead, we'll need a fixup PR after both of these land adding the kebab-case error codes to errors.md and updating the ones used in the tests.

[aphillips]

Good start.

[aphillips]

One change proposed, otherwise looks good.

[gibson042]

I like this use of the singular, and would suggest that the previous part of this document be updated accordingly (but for consistency, I think similar phrasing should be used for all sections in this PR).

[eemeli]

As discussed yesterday and following @gibson042's suggestion in #774 (comment), I've now dropped the Selection Error and Formatting Error types.

However, while doing so, I noticed that Selection Error was used in two places by our current spec:

1. During pattern selection, for selectors that don't support selection. So I added Bad Selector for this, as a resolution error.
2. In the :number MatchSelectorKeys() call, for variant keys that aren't numbers or plural categories. So I added Bad Variant Key for this, as a message value error.

In total, this means that two somewhat generic error types are replaced by two very specific ones.

I also think we should consider adding something like Bad Formatter for placeholders that use a selection-only function annotation. As with Bad Selector, that error isn't really emitted by the function implementation, but by the MF2 implementation. But we can handle this as a separate next step.

[aphillips]

Looks good! Mostly editorial suggestions.

[catamorphism]

LGTM