feat: add log_response_max_length option to truncate logged command responses

[DaPillah]

Proposed changes

Some instrument commands (e.g. an oscilloscope's CURVe?) can return responses of many
megabytes to gigabytes. tm_devices logs each response in full, which can create huge log
files that are impractical to open and can fill the disk.

This adds two ways to cap how much of a command response is written to the logs, as discussed
in the issue:

1. Global config option log_response_max_length (Optional[int], default None) —
   truncates all logged responses to N characters. It follows the existing log_* config
   convention, so it is automatically forwarded to configure_logging().
2. Per-command argument log_response_max_length on query(), query_binary(), and
   query_raw_binary() — truncates the logged response for a single call. None (the default)
   defers to the global option; an integer overrides it (0 suppresses the response contents).

When a response is truncated, the log entry keeps the start of the response and appends a clear
marker, e.g.:

Response from 'CURVe?' >>  '#512500...' [... response log truncated]

The default (None) disables truncation, so existing behavior is unchanged unless a user opts
in. The full, untruncated response is always still returned to the caller. Only the log entry
is shortened.

Addresses #396

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Functionality update (non-breaking change which updates or changes existing functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• CI/CD update (an update to the CI/CD workflows, scripts, and/or configurations)
• Documentation update (an update to enhance the user experience when reading through the docs)

Checklist

• I have followed the guidelines in the CONTRIBUTING document
• I have signed the CLA
• I have checked to ensure there aren't other open Pull Requests for the same update/change
• I have created (or updated) an Issue to track the status of this update/change and updated the link in this PR description using the wording Addresses #396
• I have performed a self-review of my code
• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• Basic linting passes locally with my changes
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• I have added necessary documentation (if appropriate)
• I have updated the Changelog with a brief description of my changes

[CLAassistant]

All committers have signed the CLA.