Provide Library Metadata

**Use cases**
* Using the feature to inspect data values schema as OpenAPIv3 schema I want to provide the `info` metadata such as `version` and `title` of the schema. (Currently these are populated with basic default values) Issue: #539
* As a ytt library maintainer, I want to provide metadata to consumers of the library. (eg: Package name, version) So they may verify a minimum version is used or include the metadata in the output.
* Add your use case ⬇️

**Describe the solution you'd like**
I want a way to provide metadata for a library. This could be through an annotation:
`#@schema/library-title "spellchecker"` or
`#@library/metadata {'title': 'spellchecker', 'version': '0.2.0'}` or
`#@schema/info {'title': 'spellchecker', 'version': '0.2.0'}`

or through a flag:
`--library-meta title=spellchecker`

**Anything else you would like to add:**
We don't currently have any library metadata features except for the [version module](https://carvel.dev/ytt/docs/latest/lang-ref-ytt-version/#docs).
This could belong in the same file as the minimum required version. [These two concepts both belong to the concept of a library](https://github.com/vmware-tanzu/carvel-ytt/issues/159).
`version.require_at_least("0.26.0")`

🤔 A consideration is **how this would play with [kapp-controller Packages](https://carvel.dev/kapp-controller/docs/latest/packaging/)** which are often used with ytt, and have a concept of metadata and versions. Is there a way to ensure the same version of a ytt library and a package? Do these two things need distinct metadata?

🤔 What do other languages/programs use to provide metadata? Some things that come to mind are go.mod, helm, java, or goland..

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

Start with the issue's proposed metadata forms and the existing version module, including version.require_at_least("0.26.0"). Review issue #159, the OpenAPIv3 schema use case, and kapp-controller Package metadata to clarify the design. Done means a decided metadata interface that supports library consumers and schema output without leaving version semantics ambiguous.

Written by the indexing model from the issue text.