Create getters and setters for dynamic Extension properties

I bet it needs few more properties (used in extension discovery) like weight

See #2024043-63: Add Module, Theme, Profile, and Extension value objects

Maybe it makes sense to introduce kinda "third party settings" for extensions objects instead of removed "info" property, ref #3035618: Extension.php code quality: declare info array as public class field

In a light of PHP 8.2 this looks major blocker as #2024043-63: Add Module, Theme, Profile, and Extension value objects shows tons of deprecations

->origin and ->subpath are additional examples, added by \Drupal\Core\Extension\ExtensionDiscovery::scanDirectory().

Removing the array return type, that's an API change on an interface, we can't do that. And fixed the required check in ModuleListForm. That's requireD, not requires and is a flag if a module is required, this change caused the module install form to attempt to install any module in the system that had any dependencies, which then unsurprisingly blew up badly.

We can't just make them deprecated, they are an API even if not explicitly defined. I guess we need a BC layer with __get/__set(), we could also use that to temporarily throw an exception on any unknown property to find others that will cause issues in PHP 8.2.

temporarily throw an exception on any unknown property to find others that will cause issues in PHP 8.2.

not sure it needed as PHP will do that for us

> not sure it needed as PHP will do that for us

Yes, but we can't reliable test yet on 8.2. I only meant as part of the process of ensuring that we define all the properties this class needs, not to actually commit it.

Thank you! It looks like neverending story so I tend to agree about split a-ka #17

Theme extensions are really a dumping ground. Found the following properties:

Yes, this changed object is huge, and by introducing it now, we're not really designing it correctly I think. Instead of trying to get all this in by 8.2/10.0 would it make more sense to just define them as properties for now?
I'm not sure if the effort to more properly define profiles would also have an impact in having seperate theme/module/profile objects? Or should that be a followup (or even a good idea?)

Looks like the latest patch also has a couple JS failures, but I haven't yet looked at why.

Just read the linked issue #2024043: Add Module, Theme, Profile, and Extension value objects, and agreeing with #17 & #20. If we want to have getters/setters it should all go in as one effort.

Note that the Extension class now has the annotation to allow dynamic properties, that's not very pretty but it means that this is no longer a blocker for PHP 8.2 support and we do not need to rush it. I didn't read the other issue just going from the issue title, but +1 to splitting into separate classes so that we can have the methods only where the make sense.

The Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

This would be helpful for Drush's PmCommands to avoid phpstan complaining when accessing $extension->origin

Re #35/#36, adding this to core/phpstan.neon.dist doesn't help contrib modules (since extending core's is a bad practice), but adding it to your own does help.

  universalObjectCratesClasses:
    - Drupal\Core\Extension\Extension