feat(phpstan): foundation for usage in extensions

[SychO9]

Changes proposed in this pull request

In #3553, we added phpstan static code analysis, but only to core code. This PR aims to make the flarum/phpstan package usable by extension repositories. Which means (at the moment) being able to pick up on new model relations and attributes.

Static analysis is actually expanded to other extensions in a separate PR for ease of readability (#3667).

There are two crucial changes/additions introduced here.

Model::cast() Extender

A new cast(string $name, string $type) extender is introduced, which allows adding type casting to attributes added to existing models from extensions. This provides three advantages:

• The feature itself is a good addition to extensions.
• Our phpstan package can tell that an attribute added to a core model from an extension is a valid class property, since those are accessed though magic methods.
• Deprecates the old dateAttribute extender, since laravel has deprecated the use of the $dates property in models for date attributes, and recommends using $casts instead. I hope in another PR to also change model classes from directly using $dates property.

Extending PHPStan

This PR also extends phpstan so that it can tell from extend.php files what relations and attributes are added to existing models, so that they aren't reported as unknown. extend.php files are parsed and currently the package looks up calls to cast and hasOne belongsTo hasMany belongsToMany method calls to inform the phpstan utility about them.

Reviewers should focus on:

• cast model extender.
• Deprecating dateAttribute extender.
• Generally PHPStan extension logic, I would focus less on the code for it.

Follow-up Tasks

• Write documentation about using PHPStan in extensions.
• Add PHPStan infrastructure to Flarum CLI.

Necessity

• Has the problem that is being solved here been clearly explained?
• If applicable, have various options for solving this problem been considered?
• For core PRs, does this need to be in core, or could it be in an extension?
• Are we willing to maintain this for years / potentially forever?

Confirmed

• Frontend changes: tested on a local Flarum installation.
• Backend changes: tests are green (run composer test).
• Core developer confirmed locally this works as intended.
• Tests have been added, or are not appropriate here.

[askvortsov1]

Maybe this string would make sense to put in a constant somewhere? Or could we reflect the model itself to get the unqualified class name?

[askvortsov1]

Same here, might be cleaner to put all these strings in one place. Deriving it from the class would be nice, but I assume impossible since then phpstan ext would need to depend on core

[askvortsov1]

There's a lot of code repetition; maybe we should consider some abstract class on top of PropertiesClassReflectionExtension for finding extenders?

[SychO9]

We can further iterate on this 👍🏼

[askvortsov1]

Sometimes I wish PHP were Hack: https://docs.hhvm.com/hack/attributes/predefined-attributes#__memoize