Fix contradiction in markup resolution

[catamorphism]

Previously, this stated that markup resolution MUST always succeed. However, resolution of u: options can fail, so that wasn't true.

[catamorphism]

I noticed this when looking at this test:

https://github.com/unicode-org/message-format-wg/blob/main/test/tests/u-options.json#L37

[eemeli]

While the resolution of individual options can fail, this still holds:

message-format-wg/spec/formatting.md

Lines 410 to 412 in 9448040

	The result of _option resolution_ MUST be a (possibly empty) mapping
	of string identifiers to values;
	that is, errors MAY be emitted, but such errors MUST NOT be fatal.

In other words, overall resolution of markup will always succeed.

If there is some language in u: options or elsewhere that implies something different, that needs to be fixed rather than changing this.

[catamorphism]

I've revised the text. This does repeat text from the previous "Option resolution" section, but I think it bears repeating.

[aphillips]

I think this could be confusing. The first normative statement (resolution of markup must always succeed) is a separate requirement. So I'd go:

Suggested change

	As with _option resolution_ for _expressions_,
	In addition, as with _option resolution_ in _expressions_,

[eemeli]

I think the more appropriate fix here would be for the "Option Resolution" section to be moved to be directly under "Expression and Markup Resolution", as it pertains to markup resolution as well as function resolution, and for its first sentence to be corrected to note that.

Then we would not need to repeat the RFC2119 language that it already includes here.

[catamorphism]

I think the more appropriate fix here would be for the "Option Resolution" section to be moved to be directly under "Expression and Markup Resolution", as it pertains to markup resolution as well as function resolution, and for its first sentence to be corrected to note that.

Then we would not need to repeat the RFC2119 language that it already includes here.

Done.

[eemeli]

Sorry, didn't mean to leave the comments above as standalone -- clicked the wrong button. This is getting really close to what we want, I think.