[9.x] Add Laravel-specific casting to the var dumper

[inxilpro]

I created laravel-dumper as a standalone package for three reasons: 1) I wanted to prove the concept, 2) I was concerned about proposing Laravel maintain its own VarDumper implementation, and 3) I wasn't sure if it was too opinionated for core.

It's now a successful package with ~300 stars and over 100,000 installs, so I think the "prove the concept" phase is done. And now that the new dd() improvements have been merged, the maintenance commitment concern has been addressed. That just leaves the "too opinionated" concern.

As a result, I've copied over much of the existing laravel-dumper implementation, but adjusted it in a few places to use more conservative defaults (and updated the implementation to match the existing Laravel core codebase).

As of now, I have custom casts for:

• The service container
• Database connections
• Database builders
• Carbon instances
• HeaderBag and ParameterBag objects
• Models
• Requests and Responses

For the most part, these casts just simplify the output and remove noise (most notably in objects that hold a reference to the service container). In a few cases, I've also reordered attributes so that the data you're most likely wanting to view is at the top, or added virtual properties for easier debugging (like a nicely formatted date/time string for carbon instances).

You can see a full list of before/after diffs in the original package repo (although some diffs may be slightly different in this implementation—especially Models).

[dennisprudlo]

No time to check the 1k diff so: Is this implemented as the new default or can one opt-in to that dumping style?

[inxilpro]

No time to check the 1k diff so: Is this implemented as the new default or can one opt-in to that dumping style?

This would be the new default. That said, each caster can be disabled individually, or you can opt to switch to the Symfony defaults with a few lines of code.

[inxilpro]

@nunomaduro what do you think of this?

[taylorotwell]

I just still am hesitant to merge this in if it's already a maintained package. It shifts the burden to our team when we really can't take on a lot more burden at the moment. Would prefer to keep this a community effort.