docs: clarify workspace type's `limitAllowedChildren` and associated fields

[embik]

We've recently had a report that was based on confusion caused by our documentation around limitAllowedChildren in WorkspaceType objects. The gist is the following:

• A WorkspaceType called "type-composite" can extend multiple other WorkspaceTypes in spec.extend.with, e.g. "type-a" and "type-b".
• Another WorkspaceType "type-limited" can limit the allowed children workspaces from certain types with spec.limitAllowedChildren, e.g. to only allow "type-a".
• It is possible to create a new child Workspace of type "type-composite" in workspaces created from "type-limited".

This is allowed because workspace type extension behaves additive and that is how the feature is intended to work. So because "type-composite" extends "type-a", limitAllowedChildren considers "type-composite" to be of "type-a".

@sttts pointed out a couple of comments across our APIs that are confusing in this regard:

Rereading our docs, this sentence clearly needs improvement:

extend is a list of other WorkspaceTypes whose initializers and limitAllowedChildren and limitAllowedParents this WorkspaceType is inheriting.

It's not clear without looking into the code what

limitAllowedChildren and limitAllowedParents this WorkspaceType is inheriting

actually means in the context of multiple workspace types being extended. I.e. is the the new limitAllowedChildren/limitAllowedParents the union or the intersection of those.

https://github.com/kcp-dev/kcp/blob/4bd4122483ff418a58315389b4f872dcaec0fe7c/sdk/apis/tenancy/v1alpha1/types_workspacetype.go#L72

And:

on .spec.extend.with we have another description of the same logic:

and for whom the owning type becomes an alias, as long as all of their required types are not mentioned in without.

Here, the last part "as long as .... in without" is left over from a beyond-MVP implementation that didn't get merged. The idea was that one can inherit some other type, but then "subtract" some behaviour.

We should improve our documentation of those fields, remove leftover comments and clearly state those effects and that they are intended. @thevilledev was kind enough to already rename functions in the code to make their intended results clear in #3298.