feat: introduce scaffold admission-request command

[flavio]

This command creates a Kubernetes AdmissionRequest object starting from a Kubernetes Resource definition.

The following command:

kwctl scaffold \
  admission-request \
  --operation CREATE \
  --object ingress.yaml

produces an AdmissionRequest CREATE event for the given Ingress object.

Currently, only the CREATE operation is supported. The other operations will be added in the future.

[flavio]

Depends on https://github.com/kubewarden/policy-evaluator/pull/548

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 47.69231% with 102 lines in your changes missing coverage. Please review.

Project coverage is 13.43%. Comparing base (ce7a88f) to head (ddd8916).

Files	Patch %	Lines
src/scaffold/admission_request.rs	57.76%	68 Missing :warning:
src/cli.rs	0.00%	21 Missing :warning:
src/main.rs	0.00%	11 Missing :warning:
src/info.rs	0.00%	2 Missing :warning:

Additional details and impacted files

```diff @@ Coverage Diff @@ ## main #880 +/- ## ========================================= + Coverage 9.71% 13.43% +3.71% ========================================= Files 24 25 +1 Lines 1801 1995 +194 ========================================= + Hits 175 268 +93 - Misses 1626 1727 +101 ``` | [Flag](https://app.codecov.io/gh/kubewarden/kwctl/pull/880/flags?src=pr&el=flags&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=kubewarden) | Coverage Δ | | |---|---|---| | [unit-tests](https://app.codecov.io/gh/kubewarden/kwctl/pull/880/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=kubewarden) | `13.43% <47.69%> (+3.71%)` | :arrow_up: | Flags with carried forward coverage won't be shown. [Click here](https://docs.codecov.io/docs/carryforward-flags?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=kubewarden#carryforward-flags-in-the-pull-request-comment) to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[flavio]

LGTM. But I have a question in mind, what happens if the user has multiple contexts in the kubeconfig? Will the catalog contains the kinds from the default context? I'm wondering about the UX for the user which is building a request for a CRDs which is not in the "default" context.

The catalog will be built from the default context.

If this is an issue at all, I don't think this is a huge issue as well and we do not need to fix it now. But if it is, is there an easy workaround for it? Like defining the context to be used or fetch resources from all the contexts ( I'm not sure if this is a good idea in end end as well ) .

Going through all the contexts would take time and also possible timeouts because maybe some of the clusters are not reachable.

It's good that you pointed out this possible limitation, but I would not focus on that right now. The scaffold code always generate something that will work for 99.9% of the policies.

We can find a solution to this corner case situation if someone complains about that.