Defer booting of schema and types

[mfn]

It's quite possible to have a project but not always need GraphQL to be fully booted.

With this PR booting the types and schema is deferred to only when the 'graphql' service truly is requested. Mostly this means artisan commands / worker / scheduler will boot faster unless you specifically use some GraphQL related features.

Benchmarks

A Private project with ~100 Types, ~50 mutations and ~30 queries, running pure artisan:
until false; do time ./artisan >/dev/null; done 2>&1 | grep real

Without this PR

$ until false; do time ./artisan >/dev/null; done 2>&1 | grep real
real	0m0.683s
real	0m0.394s
real	0m0.425s
real	0m0.399s
real	0m0.390s
real	0m0.440s
real	0m0.401s
real	0m0.404s
real	0m0.413s
real	0m0.413s
real	0m0.392s
real	0m0.414s
real	0m0.420s
real	0m0.398s
real	0m0.410s
^C

With this PR

$ until false; do time ./artisan >/dev/null; done 2>&1 | grep real
real	0m0.527s
real	0m0.322s
real	0m0.343s
real	0m0.377s
real	0m0.330s
real	0m0.322s
real	0m0.379s
real	0m0.319s
real	0m0.344s
real	0m0.374s
real	0m0.327s
real	0m0.326s
real	0m0.382s
real	0m0.324s
real	0m0.334s
real	0m0.388s
real	0m0.321s

Even this the small project I tested, the savings can be ~50 to ~100ms.

Implementation detail

Booting the types is a recursive behavior because types itself may reference the facade via GraphQL::type(…), that's why the types cannot be booted correctly within the singleton registration itself. This is especially true for interfaces.

For this reason afterResolving is used, which ensures the service is also properly registered.

[mfn]

@crissi I tested this also with a private mid-sized project (test suite and actual app), seem to work as intended; what do you think?

Wishful thinking would be to make it truly a deferred service provider but that's not possible as long as it needs to boot things; and "publishes" are required at least when wanting to publish the config and routes are not possible to defer (at least to my knowledge).

[mfn]

Forgot to mention: this was tested with lazyload_types=false or rather on a version of the library not yet having it.

Together with lazy loading the gain is likely not so noticeable.

[crissi]

Looks good