Adapt to Apify's "multiple storages" functionality

[janbuchar]

This is a feature that should complement the unnamed non-default storages:

1. Apify passes a JSON object with additional storage IDs to the Actor via environment - ACTOR_STORAGE_IDS - we should add this to the Configuration class. It is an object with three properties - datasets, keyValueStores and requestQueues. Each of these properties contains a name -> ID dictionary.
2. We should extend the AliasResolver class to utilize this so that Dataset.open(alias="additional-dataset") just works (™️). If an unknown alias is requested, we can either fall back to the current logic (create it, put an ID into the default KV-store) or shout at the user.

See https://apify.slack.com/archives/C07ED56TA1K/p1770217755895989

[Pijukatel]

While Apify-based usage of this feature is quite straightforward, the local usage of this feature has some open points.

Example:
Imagine this pre-existing storage mapping:

"datasets":{"default": "some_id", "custom": "some_custom_id"},

On the Apify platform, this will imply that specific storage from the mapping can be opened by id or alias:

await Actor.open_dataset(id="some_custom_id") == await Actor.open_dataset(alias="custom")

This will be naturally supported by the AliasResolver on the platform, which, behind the scenes, resolves the alias to id and it always opens alias storage by id in the end.

Locally, this is currently not possible as the FileSystemStorageClient is in Crawlee repo where there is no such thing as AliasResolver (SDK repo)

so locally

await Actor.open_dataset(id="some_custom_id") != await Actor.open_dataset(alias="custom")

which is very much breaking this feature