[Feature]: Built-in policy presets that configurations can extend

### Background and motivation

Getting started requires deciding, from a blank file, which SPDX identifiers to allow. Most people do not know off-hand whether `0BSD`, `Unlicense`, `BSD-3-Clause-Clear`, `Zlib` or `ISC` belong on their list, and they certainly do not know every variant they will encounter. The realistic outcomes are a list that is too narrow (constant false failures) or too broad (a policy that permits everything).

This is a knowledge problem, and it is the same knowledge problem for every user. It should be solved once, in the tool.

**Proposal**

Support extending a built-in preset:

```json
{
"extends": "packageguard:no-copyleft",
"settings": {
"deny": { "packages": ["InternalLegacyThing"] }
}
}
```

Candidate presets:

- **`packageguard:permissive-only`** — MIT, Apache-2.0, BSD-2/3-Clause, ISC, 0BSD, Unlicense, Zlib, MS-PL and similar. The safe default for proprietary and commercial products.
- **`packageguard:no-copyleft`** — permissive plus weak copyleft such as LGPL and MPL-2.0, which are generally acceptable when merely linked. Denies GPL, AGPL, SSPL and BUSL.
- **`packageguard:no-network-copyleft`** — permits GPL but denies AGPL and SSPL. This is the right shape for SaaS, where the network clause is the actual concern.
- **`packageguard:oss-friendly`** — permits essentially everything OSI-approved, denying only non-commercial and source-available licenses such as BUSL and Elastic.

Design points:

- **Merge semantics.** These must be defined precisely and documented. Local `deny` should win over an inherited `allow`, and local additions should extend rather than replace inherited arrays. This should be consistent with the existing hierarchical config merging so there is one mental model rather than two.
- **Multiple presets.** `"extends": ["packageguard:permissive-only", "./company-baseline.json"]` covers the common organisational case where a company-wide policy lives in a shared file.
- **Local and remote paths.** Extending a relative path in the repo is clearly useful. Extending a URL is tempting but introduces a network dependency and a supply-chain question of its own in a supply-chain tool; probably worth deferring.
- **Inspection.** A `--print-effective-config` flag matters here. Once inheritance is involved, users need to see the resolved policy, and it doubles as a debugging aid for the existing hierarchical merging.
- **Versioning.** Presets will need to change as new licenses appear. Changing one silently alters everyone's policy on upgrade, so the changes belong in release notes and arguably deserve versioned names.

Presets should be documented with their exact contents in the README, so nobody has to take the name on trust.

### Alternative Concerns

- The README could simply contain copyable example lists. That is much cheaper, and worth doing regardless, but the lists then never get updated in existing repositories.
- `packageguard init` (proposed separately) generates a config from what is actually in the repo, which solves the blank-page problem from the other direction. The two complement each other: `init` can suggest the closest matching preset.

### Are you willing help with a pull-request?

No

Read the README and the existing hierarchical configuration-merging behavior first, then trace the configuration handling entry point; no source file or test is named in the issue. Done means the preset inheritance, merge semantics, multiple extends, effective-configuration inspection, versioning, and exact README contents are defined and implemented consistently.

Written by the indexing model from the issue text.