[11.x] use promoted properties

[browner12]

this commit uses promoted properties to remove a lot of boilerplate code.

I avoided promoting any public properties that lacked type-hints, but had type-hints in the constructor signature. while unlikely to cause issues, this technically is a change in behavior, and should be handled against the master branch.

I did upgrade protected properties that lacked type hints to the type hint provided in the constructor signature. This should be okay because even though the properties themselves weren't type-hinted, the only way to update them was through a type-hinted constructor.

some styling decisions made in this PR:

• ALWAYS use multiline constructors, with each parameter on a new line. provides for very simple to grok git diffs.
• use a trailing comma in multiline constructors
• leave in constructor docblocks for now. could/should be removed eventually

there are many more to go, but wanted to test the waters with how this would be received first.

[browner12]

random question, but is there a reason we're still using StyleCI?

it would be great to have a configuration option to allow for single line empty bodies (as you often see in constructors with promoted properties), but as far as I can tell, that isn't possible.

would it make sense to use Pint to format the framework?

[taylorotwell]

@browner12 can you actually send this to master?

[crynobone]

would it make sense to use Pint to format the framework?

StyleCI rarely changes the laravel preset making reformatting from a PR a small change, Pint however still accepts new default for laravel preset making it hard to maintain (merge conflict, out of sync PRs etc)

[cosmastech]

StyleCI rarely changes the laravel preset making reformatting from a PR a small change, Pint however still accepts new default for laravel preset making it hard to maintain (merge conflict, out of sync PRs etc)

Glad to know that folks who work at Laravel see this as a problem too. @crynobone

Using Pint with the laravel default is a non-starter for me, since it's liable to change on a release of pint, increasing PR review burden and making change history a nightmare.

The workaround I've taken is to just copy all of the defaults that are currently set and create our own pint.json file. This could be an option for the framework as well.

[timacdonald]

@cosmastech, I recommend pinning a specific version of Pint, rather than a range. That way you choose when to update and receive potential rule changes.