Provide a way to easily update nested bundles

# **Describe the problem/challenge you have**

an imgpkg bundle with referenced nested bundles can be generalized as a directed acyclic graph. Updating any node in this graph, requires also updating its parent node. The larger the graph the more 'steps' are needed to perform an 'update'

discovering and updating the graph requires multiple steps and is not trivial.

Practically speaking, In order to keep bundles up-to-date custom automation needs to be built by users of imgpkg.

## example:
a 'simple' graph might look like this.

`rootBundle` -> `child Bundle A` -> `child Bundle B`

the current workflow to update `child Bundle B` is:

1) Update child bundle B
1.1) push this bundle and keep reference of the sha
2) Update child bundle A using the sha from 1.1
2.1) push this bundle and keep reference of the sha
3) update rootBundle using the sha from 2.1
3.1) push this bundle

# **Describe the solution you'd like**

A proposed workflow:
1) Update child bundle B
1.1) push this bundle with a tagged semver version (or some other way of declaring a version for a bundle. Perhaps use the bundle.yml `meta` field to specify a version?)
2) Run an imgpkg command to update the nested bundles.

some strawperson ideas (feel free to burn 'em down):

i.e. `imgpkg update -b rootBundle --version major,minor`
would update rootBundle's images.yml with nested bundles that have a major,minor version bump (based on the tag, or however a version is associated to a bundle)

i.e. `imgpkg update -b rootBundle --version latest`
would update rootBundle's images.yml with nested bundles to the latest version bump (based on the tag, or however a version is associated to a bundle)

**Anything else you would like to add:**
https://kubernetes.slack.com/archives/CH8KCCKA5/p1625001740185600

# Open questions / concerns
- How does this work with the version controlled source code of the bundles?
-- Perhaps a github action or CI/CD tooling with documentation on carvel.dev is a good alternative approach to this problem?
- does `imgpkg update` bump the version of the intermediate bundles it updates?
- showing a 'preview' of what it intends to update before pushing the bundles to a registry would be important. To avoid unexpected updates to occur.
-- perhaps a --dry-run flag?
- careful consideration will need to be taken around when bundles are 'relocated'. (imgpkg copy)
-- how will tags be kept in-sync across registries? (this wouldn't be an issue if we don't capture the version in the tag. i.e the bundle.yml instead)
- relying on tags comes with additional complexity and security implications
- how will this work with tarballs?

---
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.