Add variables that can replace compset regex matches in config_component and similar files

This idea has been a constant refrain for me over the last few years, but I have brought it up in the context of other issues – see especially #119 and #1522. (Update 2026-03-09: #119 is now https://github.com/ESCOMP/CMEPS/issues/640.) It's finally time that it gets its own issue.

I find the current system for matching various component options via regex matches on the compset long name in config_component.xml and similar files to be fragile and error-prone. We've had a number of bugs over the years due to too-specific or too-general regex matches in some component's xml file, and even though I consider myself decent with regexes, I still get nervous any time I need to write a new match in config_component.xml. I would like cime to do some initial parsing of the compset long name, creating a set of variables that could then be used for matches in config_component.xml, etc., without resorting to regex matching the whole compset long name. This way, the regex parsing would be done in a single place, which could be made robust and well-tested. For each component (I'm using lnd as an example), we'd have variables like:

- lnd_name: Any number of alphabetic characters - e.g., "CLM"

- lnd_version: Any number of numeric characters following the lnd_name - e.g., "50" (may be empty for some components)

- lnd_opts: Any number of options following the '%'. This is a key one. It would allow us to replace xml that currently looks like this:

```xml
-bgc sp
-bgc bgc
-bgc sp
-bgc bgc
```

with simply

```xml
-bgc sp
-bgc bgc
```

- lnd_type: One of 'active', 'data', 'stub' or 'coupler_test'. It's important to be able to match on lnd_type='active'. The other 3 are less important, because we're unlikely to rename DLND, SLND, XLND, but I'm including them for consistency.

For some more examples and thinking around this issue, see https://github.com/ESMCI/cime/issues/1522#issuecomment-307963098 and https://github.com/ESMCI/cime/issues/1522#issuecomment-308194748 and some follow-on comments in that issue.