Support "standard interface" parameters for modules (see r10k)

[reidmv]

Use Case

R10K's Puppetfile original module syntax is irregular. To support easier integration with external data sources, we recently implemented the following standard interface parameters for modules.

modules:
  - name: "puppetlabs-concat" # without any other params, still defaults to Forge, latest

  - name: "puppetlabs-stdlib"
    type: "forge"
    version: "6.5.0"

  - name: "nameof-module"
    type: "git"
    source: "https://example.com/repo.git"
    version: "branch-or-sha-or-tag"

The standard interface parameters are Name, Type, Source, Version.

Notably for sources of non-forge types, highly specific parameter names like "ref" and "branch" can be discouraged when standard interface parameters are available.

In R10K this was pushed to A) create a simpler API for external tools and data sources to interact with, B) create a more straightforward schema for humans to read, C) pave the way for supporting other types of sources for modules besides Forge and Git.

Applying the same schema across the ecosystem, including in Bolt, is desirable for all of those reasons as well as multiplier benefits of using the same schema for the same kind of data ecosystem-wide.

Describe the Solution You Would Like

Support specification of modules in bolt-project.yaml using the same standard interface parameters as we now support in r10k.

Describe Alternatives You've Considered

Use new and unique schemas for every tool in the ecosystem that deals with enumerating modules and their versions/sources. When dealing with the need for backwards compatibility, don't also support standard interface parameters.

I've considered this alternative, but it seems rather awful, honestly.

Additional Context

Another ecosystem tool which will eventually need to do the same kind of thing—enumerate modules, their sources, and desired versions—is CD4PE. Adopting a clean ecosystem standard schema smooths the path for CD4PE once it gets there too.