Clarify workflow for getting the metriq job id

[willzeng]

Right now the README instructions say:

If running on quantum cloud hardware, the job will be added to a polling queue. The status of the queue can be checked with

python metriq_gym/run.py poll --job_id <METRIQ_GYM_JOB_ID>

where <METRIQ_GYM_JOB_ID> is the assigned job ID of the job that was dispatched as provided by metriq-gym.

It is not clear to the user where / how to obtain the job ID. One can find it in the .metriq_gym_jobs.jonsl file. Some approaches for solution:

1. Tell users to open the .metriq_gym_jobs.jonsl file to find their job id. Cons: (i) over time this file will get quite long and likely not that human readable (ii) you need to switch from working in terminal / notebook to opening up a source file and locating the last job, adding extra steps.
2. Once the new 'list-jobs` command in the PR for feature: add list-jobs cli action. #96 is merged we could tell the user to run that command to get the job id. The downside is that this adds a separate step every time for getting a job id.
3. We could improve the output of run.py to (i) print the job id as a string that can easily by copied and pasted and (ii) surpress the current logging of things like the IBM queue different transpiler passes to make that printed job id more obvious. The logging could be put behind a --verbose flag. If there are multiple jobs then the list-jobs command can help users keep track on the CLI.

I lean towards doing both 2 and 3 of these options.

Thoughts? Other ideas for how to improve this workflow? @vprusso @cosenal @WrathfulSpatula

[cosenal]

We can run list-jobs (the underlying action, not the cli command) by default whenever the user doesn't pass any job_id to the poll command, and let the user pick the job from the ones listed in the same interaction.