Editorial: fix an invariant for [[GetOwnProperty]]

[bakkot]

Fixes #3253.

Calling this editorial because it's not currently coherent with text in the surrounding section. It's debatably normative though.

The constraints are sometimes worded in a slightly confusing way. The intended constraints on GetOwnProperty are:

• No constraints on how configurable: true properties can change
• configurable: false + writable: true properties can change value and can become non-writable, but no other changes are allowed
• configurable: false + (writable: false or accessor) properties cannot change in any way
• properties cannot be created on non-extensible objects

These are clearly the intended constraints, especially if you read the NOTE:

As a consequence of the third invariant, if a property is described as a data property and it may return different values over time, then either or both of the [[Writable]] and [[Configurable]] attributes must be true even if no mechanism to change the value is exposed via the other essential internal methods.

Currently the wording for one of the invariants says that if any property other than [[Writable]] can change then it must be configurable. But that doesn't match the intended constraints: in fact the [[Value]] should be able to change as well when the property is writable, even for non-configurable properties.

(The fact that [[Value]] can't change for non-writable non-configurable properties is already covered by the invariant before this one.)

---

Sidebar: maybe we should rework this section to be easier to understand.

[mhofman]

• configurable: false + writable: false properties cannot change in any way

Nit: if configurable === false and writable !== true, properties cannot change in any way

Otherwise accessor properties are not covered.

[bakkot]

Updated the description, thanks.

[michaelficarra]

I don't like the wording in this section.