[Feature Request] Guide against single-file structure

Is your feature request related to a problem? Please describe.

Given this single-file pattern of running a Workflow inside a Worker:

https://github.com/temporalio/samples-python/blob/7b3944926c3743bc0dcb3b781d8cc64e0330bac4/hello/hello_activity.py#L47-L64

there is potential (and one past instance I know of) for people learning based off of samples to think that in order to run a Workflow, you need to run it inside an async with Worker. When they try to develop an application based on that paradigm, they run into a number of issues.

Describe the solution you'd like

Make it clear that when developing, we recommend:

• running a worker separately from workflows
• defaulting to a single worker for all workflows, not one worker per workflow

We could make it clear by structuring all samples that way. OTOH I like the brevity of the single file samples. Another possibility is changing the comment. The drawbacks to that are:

• some people don't read comments
• the comment might not be clear, unless you point to a multi-file sample, what exactly we recommend doing

Comment is currently:

# While the worker is running, use the client to run the workflow and
# print out its result. Note, in many production setups, the client
# would be in a completely separate process from the worker.

Perhaps could be:

# Use the client to run the workflow and print out its result. 
# NOTE: when developing, we recommend starting out running a 
# single worker that has all your workflow and activities and
# running client code in a separate process. See, for example,
# how the encryption sample has a separate files to run:
# worker.py runs the worker and starter.py uses the client.

Commencez par hello/hello_activity.py, lignes 47-64, et comparez sa configuration de Worker et de workflow dans un seul fichier avec worker.py et starter.py de l’exemple de chiffrement. Déterminez si les indications doivent figurer dans la structure de l’exemple ou dans les commentaires, puis mettez à jour les exemples concernés afin que des processus Worker et client distincts, avec un Worker servant les workflows, soient clairs et cohérents.