feat(ws): Implement DELETE endpoint for WorkspaceKind

[andyatmiami]

⚠️ No GH Issue ⚠️

• Added the ability to delete a specific WorkspaceKind via a new DELETE API endpoint.
  • DELETE /workspacekinds/{name}
• Updated the README to include the new endpoint details and added corresponding tests to ensure proper functionality and error handling for various scenarios, including validation and authorization checks.
• Swagger files regenerated

The implementation is more or less a "carbon copy" of how it is implemented for Workspaces with the exception of the need to handle the Conflict that can be returned by the admission webhook. While there is basic handling of this condition in the PR - I'm not necessarily happy with it.

First off, there is an error message prefix inserted by kubernetes itself:

curl -X 'DELETE'   'http://localhost:4001/api/v1/workspacekinds/jupyterlab'   -H 'accept: application/json'
{
	"error": {
		"code": "409",
		"message": "admission webhook \"vworkspacekind.kb.io\" denied the request: Operation cannot be fulfilled on WorkspaceKind.kubeflow.org \"jupyterlab\": WorkspaceKind is used by 2 workspace(s)"
	}
}

The admission webhook \"vworkspacekind.kb.io\" denied the request: is appended on the error message returned from workspacekind_webhook.go and not easily able to be omitted (without falling back to brittle string parsing). I personally don't think that is appropriate details to put in an error message that could be surfaced in the UI. And while a Conflict error today is the only surfaced from the workspacekind webhook code if a workspace is using it - I'm not confident that condition would hold in the future... and there is no other information I can reliably act on to distinguish this particular cause (to simply provide a more succinct error message in repo.go)

Furthermore, our testing framework does not currently run with webhooks - so I have deliberately NOT added a test case for this behavior.

[google-oss-prow]

[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 thesuperzapper 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

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[caponetto]

@paulovmr we'll need a frontend counterpart for this new endpoint.