design-proposals: Allow custom guest CPU topologies within instancetypes

[lyarwood]

What this PR does / why we need it:

At present users of the instancetype.kubevirt.io/v1beta1 API and CRDs are able to define a CPU topology for a VirtualMachine through a combination of vCPUs provided by the guest attribute of an instance type and an optional topology provided by the preferredCPUTopology attribute of a preference.

This design proposal aims to extend the API to allow for an optional guest CPU topology to be provided by a referenced instance type instead of a generic number of vCPUs.

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged): Fixes #

Special notes for your reviewer:

This PR also introduces a dedicated instancetype.kubevirt.io directory for design proposals related to the API and CRDs.

Checklist

This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR. Approvers are expected to review this list.

• [ ] Design: A design document was considered and is present (link) or not required
• [ ] PR: The PR description is expressive enough and will help future contributors
• [ ] Code: Write code that humans can understand and Keep it simple
• [ ] Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
• [ ] Upgrade: Impact of this change on upgrade flows was considered and addressed if required
• [ ] Testing: New code requires new unit tests. New features and bug fixes require at least on e2e test
• [ ] Documentation: A user-guide update was considered and is present (link) or not required. You want a user-guide update if it's a user facing feature / API change.
• [ ] Community: Announcement to kubevirt-dev was considered

Release note:

NONE

[kubevirt-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: Once this PR has been reviewed and has the lgtm label, please assign rmohr for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files: - **[OWNERS](https://github.com/kubevirt/community/blob/main/OWNERS)** Approvers can indicate their approval by writing `/approve` in a comment Approvers can cancel approval by writing `/approve cancel` in a comment

[kubevirt-bot]

@lyarwood: Closed this PR.

In response to [this](https://github.com/kubevirt/community/pull/283#discussion_r1568831363): >@fabiand so after some back and fourth with a few people it looks like the only thing really missing from the current API is an ability to spread vCPUs across sockets, cores *and* threads in order to mimic SMT within the guest. We shouldn't need to allow custom topologies for this and I think we can get away with extending the existing `preferSpread` `preferredCPUTopology`. > >A very rough draft of this idea is available here https://github.com/kubevirt/kubevirt/pull/11729 and I'll also follow up with a design proposal. As a result I'm going to close out this PR. > >/close Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.