feat: Integrate browserforge fingerprints

[Pijukatel]

Description

Integrate browserforge package and use it's fingerprint and header generation capabilities to enable fingerprint generation in PlaywrightCrawler

Issues

• Will be documented later by Create a new guide about how to not get blocked #481 , which already has decent PR docs: Add a new guide on how to avoid getting blocked #576
• Closes: Add init script for Playwright browser context #549

Open for discussion:

1. Javascript injected script (src/crawlee/fingerprint_suite/_injected_page_function.py)

• Extracted from utils and fingerprint_injector
• Removed all type-script specific syntax( it does not work when used through Python's Playwright)
• Merged into standalone file without any imports.
• Wrapped in function that can be called with single argument -> fingerprint

Having such modified duplicated code in Python repo is not nice and is not practical when the original gets updated.
Proposal: Refactor JS code to make this a standalone-file without any dependency and without Typescript syntax. Download this single file from Javascript repo either on installing the crawlee or dynamically when running PlaywrightCrawler with fingerprints.

2. How can users use it? Currently I followed JS implementation https://crawlee.dev/docs/guides/avoid-blocking#customizing-browser-fingerprints

Which in Python looks for exmaple like this

crawler = PlaywrightCrawler(
    headless=True,
    browser_pool_options={
        'use_fingerprints': True,
        'fingerprint_generator_options': {
            'browser': 'edge',
            'os': 'android',
            'screen': Screen(
                min_width=min_width, max_width=max_width, min_height=min_height, max_height=max_height
            ),
        },
    },
)

It is a little bit clumsy as we pass so many nested options to internal objects of Crawler. Any better proposals?

3. Fingerprint QA?
How do we ensure that generated fingerprints are good? While writing tests I found out that around 5% fingerprints (specifically the headers) generated from the browserforge are not good and they will break the requests. I did a simple function to catch that specific problem, but how many more are there that I haven't found?

4. Keep our own header generation or rely on browserforge?
@vdusek already created header generation function. It is different implementation of browserforge HeaderGenerator. Do we keep both?
In this PR I kept our header generation unless 'use_fingerprints': True. If using fingerprints from browserforge, then I use header generation from browserforge as there is some basic logic to make header and fingerprint somewhat consistent (especially UserAgent).

5. Keep browser forge tightly integrated or just create example of how people can integrate it, but not have it available by default?

[barjin]

Good job! Why don't we use browserforge's injector module for this? Do we need more control over the fingerprint than browserforge can offer us?

[barjin]

By default, Playwright waits until the load event (i.e. until the HTML has loaded and all the subresources - images, stylesheets - loaded too).

I don't have a strong opinion here; I'm just curious - did this make a change in some behavior during the development? 👀

[Pijukatel]

No, I forgot it there when I was testing stuff. It is not needed. Good catch.

[Pijukatel]

Good job! Why don't we use browserforge's injector module for this? Do we need more control over the fingerprint than browserforge can offer us?

I was not aware of that. Wow, that guy did everything. I will try to use that injector,

[Pijukatel]

(This can be simpler if we decide to rely purely on browserforge and remove our own header generation. )

[Pijukatel]

I am confused why code below is shown as changed. There was no change to this in any commit in this PR