Indicating support for `OSC 52` like this is quite a recent initiative,
but terminal-side support has already been merged in foot, WezTerm,
Contour and Windows Terminal. To me, it seems like a much more sensible
interface than the existing `XTGETTCAP` and `XTQALLOWED` methods
(although dte does already support the former).

See also:

* contour-terminal/contour#1761 (comment)
* https://github.com/contour-terminal/vt-extensions/blob/master/clipboard-extension.md#feature-detection
* https://codeberg.org/dnkl/foot/pulls/2130
* https://github.com/wezterm/wezterm/pull/7046/files
* microsoft/terminal#19034
* tmux/tmux#4532
* tmux/tmux#4539

Additional context for why I consider `XTGETTCAP` flawed:

* https://codeberg.org/dnkl/foot/issues/1701
* ghostty-org/ghostty#1699

Some applications that make use of the `OSC 52` clipboard sequence will
only do so if they can be certain that the terminal actually has that
functionality. Indicating our support for `OSC 52` in the `DA1` report
will give them an easy way to detect that.

`OSC 52` support was added to Windows Terminal in issue #5823, and to
ConHost in issue #18949.

Support for writing to the clipboard is indicated in the primary device
attributes report by the extension parameter `52`. This is obviously not
a standard DEC extension, but it's one that's been agreed upon by a
number of modern terminals. The extension is only reported when writing
to the clipboard is actually permitted (Windows Terminal has an option
to disable that).

I've updated the Device Attributes unit test to check that we're
reporting extension `52` when clipboard access is enabled, and not
reporting it when disabled.

- [x] Closes #19017
- [x] Tests added/passed

(cherry picked from commit 00ee884)
Service-Card-Id: PVTI_lADOAF3p4s4AmhmQzgbpe4k
Service-Version: 1.22

## Summary of the Pull Request
Some applications that make use of the `OSC 52` clipboard sequence will
only do so if they can be certain that the terminal actually has that
functionality. Indicating our support for `OSC 52` in the `DA1` report
will give them an easy way to detect that.

## References and Relevant Issues
`OSC 52` support was added to Windows Terminal in issue #5823, and to
ConHost in issue #18949.

## Detailed Description of the Pull Request / Additional comments
Support for writing to the clipboard is indicated in the primary device
attributes report by the extension parameter `52`. This is obviously not
a standard DEC extension, but it's one that's been agreed upon by a
number of modern terminals. The extension is only reported when writing
to the clipboard is actually permitted (Windows Terminal has an option
to disable that).

## Validation Steps Performed
I've updated the Device Attributes unit test to check that we're
reporting extension `52` when clipboard access is enabled, and not
reporting it when disabled.

## PR Checklist
- [x] Closes #19017
- [x] Tests added/passed

(cherry picked from commit 00ee884)
Service-Card-Id: PVTI_lADOAF3p4s4Axadtzgbpe4g
Service-Version: 1.23