[release/7.0] Add back setter for scaffolded collection navigations

[ajcvickers]

Port of #30311
Fixes #30286

Description

The generated code when reverse engineering (scaffolding) from an existing database was changed to drop the setter from collection navigation properties. The setter is not needed for EF use cases, so this made the generated code cleaner. However, it turns out that:

• Like to use the setter to set an entirely new collection, even though it isn't really designed to be used that way
• Some serializers, notably System.Text.Json, ignore properties without setters, even though the property is pre-initialized and so is never null or needs setting.

Customer impact

Multiple customers prefer the previously generated code, and, more importantly, System.Text.Json no longer serializes entities correctly. There is a workaround--customize the T4 template to add the setter.

How found

Multiple customer reports on 7.0.

Regression

Maybe, if you squint. This isn't a runtime code change; it requires the user to generate new code. However, the code generated is different than it used to be.

Testing

Tests updated.

Risk

Low. No quirk, because this is tooling code. However, the T4 template can be customized to generate whatever the user wants.

[ErikEJ]

Maybe add docs about how to revert to the current "no setter" state?

[bricelam]