Revisit workflow of Qiskit Serverless docs

[abbycross]

Closes #4144. cc: @pandasa123 @acastellane @ElePT

• Include a high-level tl;dr: overview of the steps
• remind users their serverless workloads won't show up on their Workloads table
• be clear about which saved account is default (this applies not just to serverless)
• where to go to find out about package versions/dependencies (also a larger question)
• add info about when a job id is actually assigned
• clearer connection with Functions?

[review-notebook-app]

Check out this pull request on 

See visual diffs & provide feedback on Jupyter Notebooks.

---

Powered by ReviewNB

[abbycross]

When @pandasa123 is back, need his feedback on the admonition regarding link-outs to the github.io page:

• Language ok?
• How many Serverless pages do we post the admonition on (just the intro, all of them, etc.)?

[abbycross]

Possible to state in our docs when the job_id is assigned in the process? - or will that be changing too? @ElePT

[ElePT]

Possible to state in our docs when the job_id is assigned in the process? - or will that be changing too? @ElePT

With Functions, we have a "serverless job_id" and a "runtime job_id". I assume that you are referring to the runtime one. I think that the platform changes will make things clearer but in the meantime, it won't hurt to add a bit more detail as to when the runtime job is expected to start. This behavior won't change this year.

Here's the gist: when a user calls function.run a serverless job is submitted. At the moment, this serverless job id doesn't show up in the workloads page. The serverless job will go through a series of statuses:
1.QUEUED
2.INITIALIZING
3.RUNNING
4.SUCCESS (error, stopped, etc are also possible)

If the function providers supports it, the RUNNING status will be split up into "sub-statuses":

1. RUNNING: MAPPING
2. RUNNING: OPTIMIZING FOR HARDWARE
3. RUNNING: WAITING FOR HARDWARE
4. RUNNING: EXECUTING ON HARDWARE
5. RUNNING: POST_PROCESSING

When the sub-status says RUNNING: WAITING FOR HARDWARE, we know that a runtime job has been submitted, and the corresponding entry is expected to appear in the workloads table. If the function doesn't implement sub-statuses, we expect the runtime job to appear at some point in the RUNNING status of the serverless job, but we won't be able to accurately know when. In any case, that point will hardly ever be the beginning of RUNNING, which is what many users expect and get confused by.