Add new HTTP helpers

[selfhoster1312]

There's now a single HTTP client for each bridge, instead of creating a new one on every request. Proxy settings are applied per bridge, and the NewHttpRequest method can be overridden by each bridge to add headers (eg. tokens/cookies).

As a bonus, the regexes are precompiled and not recompiled in the hotloop of parsing attachments.

This should be tested before merging!

[poVoq]

Since we tested this with the Matrix bridge and it works as expected I guess we can merge this now?

[selfhoster1312]

Since we tested this with the Matrix bridge and it works as expected I guess we can merge this now?

I still need to add docs in docs/development/protocol.md

Otherwise i think it's working as expected. I'd like to have opinions from other bridge contributors before merging, but i don't think it's required.

[selfhoster1312]

This has been successfully tested with #23 and #61 in #63.

I should just add some docs in the "building a new protocol/bridge" docs about the new helpers.

Another feedback was that failure to download the attachment produces a silent error in bridge rooms and is only visible in matterbridge logs:

[0347]  WARN xmpp:         [handleDownloadFileInner:matterbridge/bridge/xmpp/xmpp.go:591] Failed to download remote XMPP OOB attachment error=Get "https://example.com/upload/019b0988-ec7f-7d3d-8636-bdd5c0673d8e/adB4R39_460swp.webp": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

I'm not sure if it's better to silently discard the message (as was the case previously), or to relay in remote chatrooms an error message that random users (especially those not familiar with matterbridge or attachment handling in general) may find confusing. Maybe that could be a setting.

Also worth noting that this behavior can be improved upon:

• if we make sure all attachments download/upload takes place in the background, we can raise the timeout value
• we could have a per-room/per-protocol/global setting to control whether an error is printed in the chat (so for example it could be printed in a IRC room where the admins reside, while not being printed to end-users in a Discord room)
• the helpers could also add a retry logic, as long as requests take place in the background

[selfhoster1312]

Read for review @poVoq