[9.x] Configurable pluralizer language and uncountables

[cesarep]

Hello!

As said previously on #41891, Pluralizer already handles all the uncountable words, so maintaining a list of those here is really redundant, the only words not listed there were already merged doctrine/inflector#194, with the exception of recommended and related for not being nouns, so i added the recommendation on the comments to request new nouns there, and keep this array for edge cases only. And while they don't release the 2.0.5 version with this merge, cattle and kin also stayed, avoiding any breaking changes.

As for the language configuration, i finally understood the errors on the last PR!
The tests on tests/Database use the Pluralizer as it's an essential part of Eloquent, however, their testcases (and the pluralizer test too) extend PHPUnit\Framework\TestCase instead of Orchestra\Testbench\TestCase, not bootstrapping the application, so it's useless to setup a getEnvironmentSetUp($app) function there. All the tests on features that depend on the Pluralizer and don't bootstrap the app will always throw an error saying the config class doesn't exist.

I used a simple $app->has('config') to check if the instance has this class, to get the config, otherwise it returns the default english version, acting as a fallback if the pluralizer is used outside Laravel, bypassing that error. A more elegant way to check if an Instance exists is most welcome of course.

I'm being insistent on this because I really believe this feature will be very useful for a lot of non-english speaking developers making apps on their languages. Me, personally, I'm using a modified version of Laravel with this.

It might be nice to also add new Orchestra's testcases for the Pluralizer with the other languages, i could contribute with the portuguese test. Inside tests/Integration/Support maybe?

I set the config path to 'app.pluralizer.language', grouping all the pluralizer related configs in one array in case someone finds a way to further extend the pluralizer with custom rules or custom words that might be set from the configs files.

[driesvints]

@cesarep remember that draft PR's aren't reviewed.

[cesarep]

I know!
I'm making a test file for portuguese to include with this

[crynobone]

This add a new dependency to illuminate/container

[cesarep]

That's weird when the test is run here it doesn't seem to use the portuguese ruleset
If i change the phpunit configs to run just the tests/Integration/Support folder where the test is located it runs just fine

When i do the full tests it seems to ignore that, and it gives the sames mistakes as here.
I'm thinking it has something to do with the static nature of the Inflector Instance, as it's used before this test when the english default is set, it remains the same after. Is there a way to force a reset on that instance?

Or we might as well go without a test. I was looking at the Inflector rules for portuguese anyway and, while it does really helps with probably 90% of the common words, there are still some inconsistencies that i'm reviewing doctrine/inflector#195

[cesarep]

In case someone knows a way to workaround this static instance issue, we should reset the instance to the desired languages when the test begins (ideally there should be a test for each available language), and back to english once it finishes, so it doesn't mess up the rest of the tests after it.
But probably is best to leave the language test out for now anyway, is there a more elegant way to remove the last commit of the PR other than a force push?

[taylorotwell]

Removed container / config dependency. Added Pluralizer::useLanguage(string) method.

[cesarep]

Oh great!!

How should this be setup on our apps?
I'm assuming on the boot function inside AppServiceProvider as we do for custom resourceVerbs for the routes?