feat: Add showCustomAttribute filter config setting to include the CUSTOM attribute as tag/label

[dol]

Adds new filters.showCustomAttribute config setting to add the CUSTOM attribute data from a queue manager or queue as metrics tag/label.

Please ensure all items are complete before opening.

• Tick to sign-off your agreement to the Developer's Certificate of Origin
• You have updated the CHANGELOG.md
• You have completed the PR template below:

What

We have the requirement to annotate queue manager and queue metrics with a custom tag or label. This information helps query the metrics based on this custom label and create alerts based on this information.
The CUSTOM attribute on queue manager and queue level can be utilized for this kind of additional information. As an IBM MQ platform team we will set CUSTOM("APP(A0123)") on a queue manager or on a queue. The new capability in this PR extracts this CUSTOM data and adds it as a tag or label depending on the collector.

How

The query request of the queue manager and queue attributes was extended to include the ibmmq.MQCA_CUSTOM data.

Testing

The change was tested locally for otel, prometheus and JSON exporter.

Issues

Open point

1. The changes to [mq-golang](https://github.com/ibm-messaging/mq-golang) were commited to the vendor folder as it's not clear how to bring the changes upstream. Should a pull request opened at mq-golang?
2. Since I don't have any expirience with IBM MQ for z/OS I'm not sure if the custom attribute is supported in that platform. For that reason the showAndSupportsCustomLabel method was created to mark it false if the platform does not support it.

[dol]

@ibmmqmet It would be nice if you could review and add it to the project.

[ibmmqmet]

I somehow missed this when first opened. But a few comments:

• The CUSTOM attribute is documented as reserved for IBM use. While I don't see it ever getting used again in future, because of changes to how new function is delivered, it really should not be considered a general-purpose user interface.
• The DESCR field (and the qmgr-wide metadata tags that can be configured in these collectors) do cover a lot of uses
• Changes to the mqmetric library would have to be done via a PR to the mq-golang repo first, and then released before they could be exploited by actual collectors. Though I could copy things piecemeal into my local repos so they could be released at the same-ish time
• CUSTOM is available for z/OS qmgrs and has been used, though again I doubt it will be used in future

I think I need to discuss locally whether or not any unintended use of CUSTOM should be condoned before deciding what to do about this.

Having said that, at least this PR looks to be well-written and follow a reasonable model.