Add docs about project structures supported by `apify init`

[honzajavorek]

The only docs about the apify init command I've found is this small section, which documents the basic usage of the command, but provides no information about how the project should be structured or how should I specify my dependencies (as in Python, approximately one billion of possibilities to specify one's dependencies exist).

How do I actorize one-file Python scripts? How do I actorize a whole packaged application? How do I specify the entrypoint?

Can I use requirements.txt? Maybe pyproject.toml? What dialects? Can I use Poetry or uv?

I think this should be documented. It's clear the tool cannot support everything, so there should be supported structures listed, and perhaps also intentionally not supported structures or workflows, either as "we don't want to do this" or "known issues we're yet to tackle".

As of now, it's not clear what apify init does exactly and what it expects me to prepare as an input.

Related to https://github.com/apify/apify-cli/issues/746#issuecomment-2713468786

[B4nan]

@vladfrangu we should improve the detection instead of just documenting the current/weird behaviour

[vladfrangu]

I agree. We should focus on making the init more interactive (try to detect the language but fall back to a picker if not working, and asking the user what the entrypoints or such are), and less... "Expecting this structure or i will break"

[B4nan]

Why do you even need to know the project type from inside the init command? We had a quick look during the team sync and it feels like we should move this to run command instead, where you actually need it. People might not need the run command, they should be fine with just running their project, whatever way they want (think npm start instead of apify run).