Having the log implementation all internal causes friction when consuming imgpkg as a library

[joaopapereira]

Describe the problem/challenge you have
imgpkg API requires, in some functions, users to have their own implementation of a logger. This can cause some friction in the adoption of the library, and we could eventually provide some implementations of our loggers

Describe the solution you'd like
Have some alternatives here:

1. Make our internal logger public.
2. Create two basic implementations with NoOp and a writer Logger

I am more biased towards having us make the internal loggers visible from the outside as long as we do not keep the hard requirement they currently have on the logging library we are using internally in imgpkg. The second option if it is only going to be used by whoever calls imgpkg as a library, could make us more vulnerable to bugs since we would not be using them in the tool.

Anything else you would like to add:
If memory servers, these Loggers were made internal so that we would not spill out some of the complexity associated with the logging library we were using, making it a bring-your-own implementation.

---

Vote on this request.

This invites 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 work on this issue.