feat(scaler): Add TLS support for Artemis scaler

[chiragbhatia8]

Description

This PR introduces TLS support for the Artemis scaler, allowing secure communication with Artemis brokers.

Checklist

• When introducing a new scaler, I agree with the scaling governance policy
• I have verified that my change is according to the deprecations & breaking changes policy
• Tests have been added
• Commits are signed with Developer Certificate of Origin (DCO - learn more)
• Changelog has not been updated and is aligned with our changelog requirements
• A PR is opened to update our Helm chart (repo) (if applicable, ie. when deployment manifests are modified)
• A PR is opened to update the documentation on (repo) (if applicable)

Related Issues and PRs

Fixes #6448

---

Notes

This PR includes:

• TLS configuration support (CA, Cert, Key) for Artemis scaler.
• Updated unit tests and metadata validation.

Testing TLS functionality directly in an e2e environment might require additional configuration.

[JorTurFer]

We pass the value here because it can be changed via ENV by users and some scaler allow overriding it via scaler configuration. Said this, maybe we should move the env evaluation to the http package and add another builder to build the client with another different timeout. This could make the code cleaner @wozniakjan @zroubalik ?

Suggested change

	// do we need to guarantee this timeout for a specific
	// reason? if not, we can have buildScaler pass in
	// the global client

Checking the current options, I'm wondering if a Builder patter can make sense in general to configure all the parameters of the HTTP client as currently we are calling multiple times to the same code, e.g: To create a client with an specific transport, we create the client (which creates a TLS config and a transport) and then we create the new transport and replace the just default created one.
I'm thinking about something like:

client, err := kedautil.NewHTTPClientBuilder().WithTimeout(...).WithTransport(...).With...Build()

It's more verbose but more efficient too, and it shouldn't be a huge change in terms of changes (to address them in another PR. If we agree with changing this, I'll create another issue)