ambiguous on disk names for component and configurations vs packages with `-` in their name

Looking at the spec for configuration merging it specifies that once a package `.cps` is found, then the following packages in the sibling directory should be loaded and merged:
- `:*.cps` (except on Windows)
- `-*.cps`
- `@*.cps`
- `:*@*.cps` (except on Windows)
- `-*@*.cps`

Per the documentation of package names (https://cps-org.github.io/cps/components.html), it appears that `@` and `:` are invalid in the package name, so should be invalid in the on-disk name as well? So a package called `code::blocks` would be invalid, it would need to be called something else, like `code_blocks`. So that seems like maybe a chance to clarify the spec?

The bigger concern I have is that `-` is allowed in package names, which means for a cps file installed directly in a cps prefix root, like `/usr/lib/cps/` there is a potential for ambiguous names to cause collisions, where a `-` is used to name a third party component, rather than a configuration or component fragment. (I will refer to these component and configuration .cps files as fragments)

Imagine:
```
/usr/lib/cps/zlib.cps
/usr/lib/cps/zlib-ng.cps
```
these are two separate projects, with two separate implementations, and should not be combined, but it's impossible to tell that without opening and reading both of them to determine that `zlib-ng` is not a fragment of `zlib`

I really don't like the idea that we have to fully parse `zlib-ng.cps` in order to reject it, it makes for longer search times and more disk i/o. A few possible solutions:
1. require that all .cps files be installed in a subfolder such that `zlib/*.cps` and `zlib-ng/*.cps` cannot be confused
2. drop `-` as a fragment separator, such that only `:` and `@` are valid. This means that we need a replacement for windows, since `:` isn't valid?
3. give fragments a different extension, like `.cpf`
4. Something else?

Start with the configuration-merging specification and the package-name documentation linked in the issue. Compare the documented separators and package-name rules with the listed on-disk examples, then resolve the ambiguity and update the specification so component fragments and packages with hyphens cannot collide.

Written by the indexing model from the issue text.