[10.x] Fixes singleton and api singletons creatable|destryoable|only|except combinations

[nunomaduro]

This pull request fixes #47088, and the usage of creatable or destroyable Singleton Resources when combined with options such as only or except.

@jessarcher Can you let know what do you think about this, before I deliver it to Taylor? Thanks!

[jessarcher]

Hey @nunomaduro

In your implementation, @timacdonald and I noticed an inconsistency between apiSingleton and apiResource. For better or worse, apiResource allows you to use the only method to enable non-API routes, but in your implementation, this was not the case with apiSingleton.

We've rolled back your change to the apiSingleton method in Illuminate\Routing\Router to work the same as apiResource by only setting an initial value for only and deferring everything else to the singleton method. We instead solved #47088 by using the creatable and destroyable options to change the "defaults" that are passed to the getResourceMethods method.

We no longer need any singleton-specific code in the getResourceMethods method, and we no longer need the apiSingleton option at all.

We've made the change as a single commit so you can roll back if you don't agree :)

[taylorotwell]

@jessarcher why was store added here?

[jessarcher]

We previously had some singleton-specific overrides in getResourceMethods that were applied after only, leading to unexpected behavior.

Now, the creatable and destroyable methods just expand the defaults that are passed to getResourceMethods, which can then be reduced by only.

We need to specify store here so that it will be included when using creatable. It's safe to include even when creatable is not called because only can only reduce the defaults, but not expand them.

[nunomaduro]

Ready for review @taylorotwell.