feat: add info package subcommand

[plobsing]

Provides one of the commands discussed in
https://github.com/orgs/aquaproj/discussions/2641

Output looks like

❯ aqua info package sigstore/cosign
{
  "type": "github_release",
  "repo_owner": "sigstore",
  "repo_name": "cosign",
  "description": "Container Signing",
  "asset": "cosign-{{.OS}}-{{.Arch}}",
  "format": "raw",
  "supported_envs": [
    "darwin",
    "linux",
    "amd64"
  ],
  "checksum": {
    "type": "github_release",
    "asset": "cosign_checksums.txt",
    "algorithm": "sha256"
  }
}

[suzuki-shunsuke]

Thank you for your contribution!

[suzuki-shunsuke]

Hmm. This command accepts multiple package names and outputs them as JSON independently.
I think it's weird because the output can't be parsed as JSON.

{
  // ...
}
{
  // ...
}

I think there are several options.

1. Accept only one package
2. Return a list of packages

[
  {
    // ...
  },
  {
    // ...
  }
]

[plobsing]

JSON is a self-delimiting format. There is no parsing ambiguity in a stream of messages. Tools like jq and libraries such as Go's encoding/json have no issues working with such streams.

For example, with the current implementation, I'm able to aggregate a count of installed packages by owner using jq:

❮ ./aqua info package $(./aqua list --installed | awk '{print $3 "," $1}') | jq -r '.repo_owner' | sort | uniq -c 
   1 golangci
   1 goreleaser
   1 int128
   1 reviewdog
   1 rhysd
   1 sigstore
   2 suzuki-shunsuke

Of the alternatives you suggest, I think I prefer "accept only one package". Its got what seems to me like an unnecessary restriction, but the output is direct and simple to work with. It is a subset of the stream-of-objects output format I proposed: just pass a single name if you want a single message of output. If we do choose to restrict the caller to requesting only one package, what should happen if they pass more than one in argv? What about zero packages in argv?

I'd really prefer to avoid the list format. I find it over-encapsulated, less human-readable, and a bit less convenient to work with. There's not really an upside.