Allow valid message invalidation with new default functions

[aphillips]

Fixes (part of) #1024. #1033

@macchiati Demonstrated that the stability policy could logically conflict with locally-assigned default-namespace functions or options. This fixes the policy to allow us to assign new values that conflict with such.

I believe the change is consistent with working group consensus.

[macchiati]

I retired the issue that had multiple sub-issues, so the description should reference #1033

[aphillips]

I merged my suggestion (you can uncollapse @macchiati's comment to see the discussion). Please comment if you want the note back or some other wording.

[macchiati]

The change is good, but just to note that it doesn't address #1033

[aphillips]

I merged @eemeli's text. I think that's an improvement. If we needed to, we could add a note calling out that a valid message can start to have errors if users or implementers have abused a reserved identifier--that should go in the stability policy section about identifiers.

With that change, I'm removing the normative tag, since it nearly reverts the sentence to its original form, only replacing the vague term "invalid" with the formal term "not valid".

[eemeli]

I think it's important for us to have a term like the current valid that a messsage can be verified to pass with no reference to anything outside the message, including functions.

I would not be opposed to defining a name for a message that we know is going to produce an error during formatting because it has operand or option values that don't pass muster, but I'd also like to note that that check is in most cases not going to prove that the message will not produce an error, because formatting relies on external values that are not necessarily known ahead of time.

[aphillips]

Merging this. Other changes to follow for the name collision parts of #1033