Add an imgpkg delete command.

**Describe the problem/challenge you have**

I want to be able to delete OCI artifacts in an image registry created by `imgpkg push` or `imgpkg copy` using `imgpkg`, rather than having to login to the web interface for the image registry, use a separate tools such as `skopeo` or by using a tool like `curl` against the image registry REST API directly to delete it.

**Describe the solution you'd like**

I want to see an `imgpkg delete` command. So if I originally did:

```
imgpkg push -i your-user/app1-config:0.1.1 -f config/
```

I want to then be able to do:

```
imgpkg delete your-user/app1-config:0.1.1
```

The `imgpkg delete` command should by default work like `kapp` and provide a metadata summary and prompt you whether you do want to delete the image or not. If you what to delete it without being prompted, then you would be able to supply a `-y` option.

Note that the expectation is that `imgpkg delete` would verify that the image you are asking to delete was in fact created by `imgpkg` and it would not by default delete arbitrary images. Attempting to delete an OCI artifact not created by `imgpkg` would be an error, unless you supplied a `--force` option.

Note that am not distinguishing between an image (`-i`) and a bundle (`-b`) when doing `impkg delete` as don't see the need to. The fact that it verifies that it at least was something created by `imgpkg` is enough.

In addition to deleting a single OCI artifact for an image or bundle, consideration also needs to be given to being able to delete a set of OCI artifacts created as a result of `imgpkg copy`. The `imgpkg delete` command in this case should be able to identify somehow that when deleting a bundle, that it was created using `imgpkg copy` and had associated OCI artifacts that go with it. In this case when prompted, the metadata should show a list of all the associated image artifacts and confirming deletion should delete all of them. As it stands this may not be possible since assume that the copied bundle doesn't contain any metadata or audit trail information to record the fact that there were associated images that go with the bundle which would also need to be deleted. That audit trail information should exist for debugging and other tracking reasons anyway, so if not present should be added for that reason anyway, as well as being useful in this case of `imgpkg delete` for deleting all associated images.

Note that for this latter use case of deleting everything created when doing a `imgpkg copy`, then perhaps by default it could warn there are associated images and list them, but warn they will not be deleted, and require an `--all-images` option to say that all associated images should also be deleted in addition to the primary bundle. If a bundle results in other bundles being copied, then maybe an `--all-bundles` option should be supplied to effectively do the delete recursively.

**Anything else you would like to add:**

An `imgpkg delete` command would be a useful complement to `imgpkg push` and `imgpkg copy` and from a user perspective would make the `imgpkg` tool look more complete as it wouldn't be necessary to go seek out a completely different way of deleting the images from the registry created by `imgpkg`.

cc @jorgemoralespou

---
Vote on this request

This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.

👍 "I would like to see this addressed as soon as possible"
👎 "There are other more important things to focus on right now"

We are also happy to receive and review Pull Requests if you want to help working on this issue.

No files or tests are identified in the issue. Start by reviewing the existing imgpkg push and copy command entry points and their registry metadata handling. Define the delete command's provenance checks, confirmation and force flags, and the expected handling of associated artifacts before implementing and testing the agreed design.

Written by the indexing model from the issue text.