feat(@angular/build): support patterns in library entryPoints

[thekhegay]

PR Checklist

Please check to confirm your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/angular/angular-cli/blob/main/CONTRIBUTING.md#-commit-message-guidelines
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Documentation content changes
• angular.dev application / infrastructure changes
• Other... Please describe:

What is the current behavior?

This is on top of #34106, which adds @angular/build:library, so there is nothing to merge it into yet and only the last commit is new. Draft until #34106 lands. cc @alan-agius4

Follow-up to #34106 (comment). entryPoints lists every entry point by hand, so a library with many of them keeps a copy of its folder layout in angular.json, and an entry point missing from it is not published without any error.

Issue Number: N/A

What is the new behavior?

A key and its entry file path can each contain one *, as with subpath patterns in package.json exports:

"entryPoints": {
  ".": "projects/lib/public-api.ts",
  "./*": "projects/lib/*/public-api.ts"
}

* matches any non-empty part of the path, including /, so nested entry points are picked up too. Explicit entries take precedence over a pattern match with the same name or the same file, which also allows renaming one or giving it its own tsConfig. A pattern that matches no files is an error. Patterns are expanded once when the build starts.

On ngwr (228 entry points, 99 of them nested) these two lines replace a 230-line map, the output is identical to the build with the explicit map, and the expansion takes ~10 ms.

Does this PR introduce a breaking change?

• Yes
• No