API Don't create "peripheral" operations by default

[chillu]

When scaffolding Page with a read operation,
the default behaviour used to be the creation of readPage, readSiteTree, readRedirectorPage etc.
In fact, the readPage query is sufficient, since it returns a union of all these types. The rest is noise,
with the slight advantage that types at the end of an inheritance chain (without descendants)
get away without unions in the return type.

The default behaviour is a bit more useful on create and update operations,
since those require a specific input type - unions aren't allowed here.
So in order to fully create subclasses, you need createPage vs. createRedirectorPage.

I'm proposing that we make this well-documented opt-in behaviour,
with the admin/graphql schema opting in for each type on create and update.
I don't see a reason why anyone would want to opt in on read or delete.

For the more common case where scaffolding is used to create a more limited readonly public schema,
this reduces the mental overhead for devs, noise in the schema itself,
and cuts down schema generation time because less "helper types" like readRedirectorPageConnectionType are required.

If this PR is accepted, we'll need to add the following to the
upgrading guide at https://github.com/silverstripe/silverstripe-graphql/releases/edit/untagged-b4d095bafd3edac22f15

---

Previously, scaffolded operations on DataObject would
create the equivalent operations on both ancestors and descendants.
If you want readPage, you'd also get readSiteTree and readRedirectorPage.
That's often not desired, so we're making it opt-in via a new cloneable config setting.
Note that it's most common to clone create and update operations,
since those rely on specific input types for a class
(e.g. createPage has createPageInputType, while createRedirectorPage has createRedirectorPageInputType).

SilverStripe\GraphQL\Manager:
  schemas:
    default:
      scaffolding:
        types:
          Page:
            operations:
              read:
              	cloneable: true

[robbieaverill]

Looks like a good idea to me. I wonder about the naming of "cloneable" though - we're indicating that children will also be scaffolded, but "clone" doesn't really indicate that to me. What do you think about something like "scaffoldChildren," "includeChildren," or "recursive"?