Start to disambiguate between types of initializers.

The README says [here](https://github.com/tc39/proposal-decorators?tab=readme-ov-file#adding-initialization-logic-with-addinitializer): > **Field and Accessor decorators:** During class construction, immediately after the field or accessor that they were applied to is initialized This [TypeScript playground example](https://www.typescriptlang.org/play/?#code/GYVwdgxgLglg9mABAEwKYTgCgN4HNVQA0iAzgQL4BciAwgDYCGJJAghBKs3AE4Ai6PBlB4AVBt3xQAPOADWYOAHcwxOQuUA+YtAAe1ek1btOJHvwzchPGgiiodUAJT7GzNhy58Bl4dwBKnCB00gxgAJ7EoWEaiNgAUIiJiLoAdAzIyACSYDCwDHQwAF6o3JigkLAIiJiOsQlJDRhgpnSoKXRwuJgA5AzGnslQOmkZ2bkw+UUl1eD2AA7odsiO3cSYUAAWMCSITLvhjinAcHC1APRniPOLqMiIAIwATADMxLhwUIjgaMAwYLfVGDARC5EE7ABE+W4qHSYRBOTyBWKyHBxE2qCQmVIGzgQTuZFQiHRiAAbvkQKhHPVEuQqdTENCoCBuEg8ARiGQiPDcjU6g0GlBuHD4vzRckEC02h0ur1+qZuAyCMykH9xpNitxVtVNttdjsoodjqd6Q1yMkhBANphKXyxY0JXBWu1Oj0+h55VduNweIr0n9cIg5twYGS7KQoEJCQAjVDHaHcxFFITwJDWnQLaC3FbnS7XTN3Ere7hvD6eosmpLkenkKtVuLlaAplACR6YAD61G+sb+t20QxchgAYjBUHRkOZBL4bGA7A5nNV1lsSNQosQyXQVwdEABeGIG22JVLpLIIiZIkplcCNqq8kVipqS50y36ju5H0an9XTTCzdM3ZZaouup7AaRwnDmVx-vmDwvCWnxdr8-x3JgQIgp8uqQnQ0KwgmZ5TCiaIbBiiBYiQOJ4qQqCEsS64UlSpp0g0jLKogDaVGAQHLvsYS1HeooPo6Uout0L5joqTIsrhX4KmmGZLCshHbGBpyIBckFyQCCE9sgcFfGAPzadUJCwHQdBSUi-r0ZWcR1hArg7AAsmEBjMAeiAAAJoBguxyj6Ro7jBzxxPSnktogUbiAFAAsACsABsNnBf8iiIE5LkkDUcRAA) shows how the behavior did not match with what people typically consider "initialized" to mean. People consider "initialized" to mean that that a property has been created and has a value. The absence of a variable typically means the variable is not initialized yet. After this change, it starts to be a little clearer what the actual behavior is, but the wording is still ambiguous: there are really two types of initializers here, and perhaps they need to concrete names to disambiguate so that people can understand more easily. For example, what if they are called - _element initializers_, ("non-context initializers" in this PR's wording) - and _context initializers_ ? Then we could say something like > immediately after element initializers have finished initializing an element's value, but before the element is defined or in the case of class fields something like > immediately after field element initializers have finished initializing a field's value, but before the field is defined on the class instance Something along these lines will help solve the ambiguous wording.