feat: Implement storage aliases

[janbuchar]

• closes Add support for non-default unnamed storages #3074

[barjin]

Thank you @janbuchar ! I have a few questions below ⬇️

[barjin]

I'm not sure I agree with this, e.g., in WCC, we create unnamed queues to pass to the subcrawlers, see:

const fileQueue = await RequestQueue.open();

const mainCrawler = new Crawler(({ req, res }) => {
    if(res is file) await fileQueue.addRequest(req);
});

const fileCrawler = new Crawler({ rq: fileQueue, ... })

In this use-case, the RQ is supposed to, e.g., survive migration and keep the enqueued file links until these are processed by fileCrawler.

I guess my point is unnamed !== exclusively used by one crawler. Perhaps we could have a similar flag as with SessionPool?

crawlee/packages/basic-crawler/src/internals/basic-crawler.ts

Lines 575 to 578 in 712a5d1

	/**
	* Indicates whether the crawler owns the session pool (it was not passed from the outside using the `sessionPool` constructor option).
	*/
	private ownsSessionPool: boolean;

[barjin]

Forgive me for being dense, but why isn't this supported? Two supporting arguments I can think of:

A) The legacy Dataset.open(idOrName: string) signature doesn't support alias, so it's unambiguous in that way. To use alias, the user has to be explicit, e.g., Dataset.open({ name: 'x' }) or Dataset.open({ alias: 'x' })

B) If this is because of the memory-storage implementation (both alias and name become folder names), then it's imo memory-storage implementation leaking into the abstraction, and we should change this. Perhaps add an indirection layer for aliases?

Is there another reason I'm not seeing?

[barjin]

nit: Given that directoryName is always populated, doesn't the last clause (directoryName) always contain the first two (id / name)?

directoryNameMatches => idMatches \/ nameMatches