[4.x] Refactor capsules and the way all classes are found/inferred

[Tofandel]

For the future roadmap

We should change capsules to simply work from a list of classes, we don't really need all the string magic, it just makes it harded to run static analysis and harder to debug when something goes wrong, this would simplify the DX of packages

1. The only required parameter should be the Model class, from which we can infer namespace, name etc
2. An optional namespace
3. An optional display name
4. Optional Repository class
5. Optional Controller class
6. Optional Slug class
7. Optional Translation class
8. Optional Revision class

We can likely register app modules as hidden capsules this way and use methods on the facade as the single source of truth for where to find a class (as opposed to the tens of sources of truth right now lost in the helpers, traits or models)

We could also allow configuration on the capsule directly for things like title key and thumbnails (which has the same design problem of no single source of truth, sometimes it comes from titleInBuckets, sometimes from titleInBrowsers, sometime from title, sometime from $titleKey, it's simply too complex)

Similarly we should allow wherever possible to use class names instead of an array of modules (eg were buckets are used ('module' => 'moduleName', 'name' => 'DisplayName')

We should also handle behaviors in the repository directly from the form builder in the controller if available, I know this is problematic when using a browser inside a block were the field name is different than the relation name for example because again the source of truth is either the key in the database or the browser config in the block, so it works the first time an element is added and then it fails to load the relation because it's inferring stuff from the field name in the database instead of loading the browser config in which it was saved

And finally we should defer twill navigation and capsule registration in packages and in the twill service provider only when they are needed, right now the providers will always run and register them even though we are not in the admin panel, this is expensive in term of classes and translations to load

[ifox]

Yes, this is exactly the direction we'd like to pursue for Twill 4+. No more strings and arrays of strings all over the place. With Twill 3 we made great progress with the form, table and navigation builders, and others changes like the setup method in controllers, but there is still a lot of work to do.