feat: Add requests argument to EnqueueLinksFunction

[Pijukatel]

Description

Add requests argument to EnqueueLinksFunction.
Split EnqueueLinksFunction implementations to extract_links and add_requests.
Add overload variants of EnqueueLinksFunction.
Raise error in EnqueueLinksFunction implementations if called with mutually exclusive arguments.

Relates to : #906

[janbuchar]

I can imagine at least two instances of confusing behavior:

1. you pass in requests and selector, the function enqueues the requests (even though their elements don't match the selector), and it extracts and enqueues some additional links from the current page
2. you pass in requests and transform_request_function, but the function won't be called

I know that the docblock makes it pretty clear that this is what will happen, but I also know that there will be bug reports about this 😁

In my opinion, we should make two overloads and throw a runtime error if someone passes both requests and one or more of the other arguments.

[Pijukatel]

I can imagine at least two instances of confusing behavior:

1. you pass in `requests` and `selector`, the function enqueues the requests (even though their elements don't match the selector), and it extracts and enqueues some additional links from the current page

2. you pass in `requests` and `transform_request_function`, but the function won't be called

I know that the docblock makes it pretty clear that this is what will happen, but I also know that there will be bug reports about this 😁

In my opinion, we should make two overloads and throw a runtime error if someone passes both requests and one or more of the other arguments.

Ok, so the function will basically become two in one alias for:

1. add_requests(requests)
2. add_requests(extract_requests(...))

[vdusek]

I agree with @janbuchar, rather be more strict here.

[janbuchar]

I now noticed that the JS counterpart accepts just urls as an array of strings. We should either restrict this, or extend the JS version 🙂

If we choose restricting this one, then most of the other parameters (barring selector) would actually start making sense in combination with urls.

[vdusek]

I would prefer to keep it as it is for consistency, since we use request: str | Request everywhere else.