Handle/document more attributes such as "dim"

[rolandwalker]

Description

Handle and document more attributes for the [colors] section of the ~/.myclirc configuration file.

This is a bit tricky as we try to support both Pygments and prompt_toolkit attribute names, and there is some mismatch between them.

Before adding any style item we check it in a try block to see if it is supported (for the software, not the terminal). This works fine, with the only downside being that we silently swallow some spelling errors, applying no style in that case. We cannot reasonably warn in all such cases, since there exist styles supported by one library and not the other.

In the end, we gain the support of new attributes such as dim and strike. Some, such as hidden, may not be supported most terminals.

Other attributes exist, such as roman, but it isn't clear that they are supported anywhere, so they are not documented.

The attribute that is most likely to be useful is dim. (I would like the border colors of tables to be dimmed).

Checklist

• I added this contribution to the changelog.md file.
• I added my name to the AUTHORS file (or it's already there).
• To lint and format the code, I ran

  uv run ruff check && uv run ruff format && uv run mypy --install-types .

[github-actions]

1. Missing regression tests for newly introduced validation/silent-drop paths
   The PR changes runtime behavior in both style_factory and style_factory_output to silently skip unsupported styles, but no active tests cover this. Existing style tests are skipped, so this behavior is currently unverified.
   • Changed logic: clistyle.py:99, clistyle.py:121, clistyle.py:151
   • Current skipped tests: test_clistyle.py:12, test_clistyle.py:24
     Action: add non-skipped tests that assert:
   • valid attrs like dim/strike are accepted where supported;
   • unsupported attrs are ignored (not crashing);
   • typo/invalid attrs do not regress startup/style rendering.

No direct security issues found in this diff.

[scottnemes]

For both these new functions, shouldn't they have a return type of bool? Surprised mypy doesn't complain about this.

For the error case of both functions, would it make sense to just return false for any exception? Otherwise it's not returning anything in the case a different error occurs (unless you want to actually do something on different errors). And seems weird one is AssertionError and one is ValueError, unless they actually do return those different error types (but would be moot if you just return false regardless).

[rolandwalker]

Good catch on the return type! We don't have mypy settings as strict as requiring them.

Yes, those are the actual expected exceptions for the two different cases, and we want to throw if some other error happens.