Allow for e.g. Content-Disposition attribute when signing urls

**Is your feature request related to a problem or challenge? Please describe what you are trying to do.**

The [signed_url](https://docs.rs/object_store/latest/object_store/signer/trait.Signer.html#tymethod.signed_url) method doesn't support attributes such as (response)-content-disposition (e.g "attachement; filename=..."), which can be useful when then signed url is meant for a browser download - the current workaround is to provide these attributes at upload time, but this requires the producer to know what the consumer will do with the data (and the producer might be a totally different system than the consumer), or to proxy the download through an endpoint that will add these headers (but it defeats the purpose of signed urls and adds a lot of bandwidth constraints to any API that would decide to do that).

Is it feasible to add such a feature? I assume the list of supported attributes would boil down to

(S3/Azure/GCS) content-disposition (`***`)
(S3/Azure/GCS) content-type (`*`)
(S3/Azure) content-encoding (`*`)
(S3/Azure) cache-control (`**`)
(S3/Azure) content-language (`*`)
Which are all supported S3/Azure, but GCS doesn't seem to support the last 3.

- (`*`): these are known by the producer most of the time
- (`**`): this might or might not be known by the producer
- (`***`): this is unlikely that the producer knows that

**Describe the solution you'd like**

The ability to specify a set of attributes (including content-disposition) to the `signed_url` method.

**Describe alternatives you've considered**

N/A

**Additional context**

Using this crate from python through obstore.

The issue identifies Signer::signed_url as the entry point; begin there and inspect how signing is implemented for S3, Azure, and GCS. Define the supported response attributes per provider and verify that callers can pass them through signed URLs, including the browser-download content-disposition case.

Written by the indexing model from the issue text.