[Feature]: Support solutions that produce more than one package

### Background and motivation

The templates assume a solution that produces exactly one package: one `MyPackage` project, one nuspec, one `Pack` target that packs `Solution.GetProject("MyPackage")`.

In practice many libraries grow into a family: a core package plus optional integration packages that keep third-party dependencies out of the core. That structure is one of the [principles of successful package management](https://www.dennisdoomen.com/2016/10/principles-for-successful-package.html) the README cites, so it is a little ironic that the templates cannot express it.

Splitting a single-package solution into several later means reworking the build script, the API verification setup, the coverage configuration and the publish step.

Proposal: offer a multi-package variant, or restructure the build script so that adding a second packable project is a small, documented change rather than a rewrite.

### Alternative Concerns

* Full multi-package support adds real complexity to the build script, and most users start with one package. Making the *existing* script generalise cleanly (packing all projects marked packable, rather than one project by name) may deliver most of the benefit at a fraction of the cost.
* API verification and coverage reporting both currently assume a single library project, so those need attention too.
* A separate template variant would multiply the combinations that need testing, which already stands at six.

### Could you help with a pull-request?

No

Start by reading the build script and templates, then inspect the API verification setup, coverage configuration, publish step, and README guidance described in the issue. Done means a solution with multiple packable projects can be supported without rewriting these areas, with the existing template combinations still tested.

Written by the indexing model from the issue text.