[core, runtime] Modify the launchers to support returning results.

[schweitzpgi]

The launchers ceased really supporting dynamic kernel results at some point. This PR adds that functionality back into the mix. This support is added pervasively across the runtime library calls.

Some notes:

• Return values of static size continue to be supported as they were before. Specifically, these values are stored into the data buffer by the thunk adaptor so they can be returned, ultimately, to the original caller.

• Return values of dynamic size follow exactly 1 of 2 possible calling conventions. The convention must be selected by the runtime layers.

  1. Everything is running within a single process; i.e., this is a simulation. In this case, the kernel will create a span of data and that span will be returned to the original caller which will use it to construct the std::vector result object.

  2. There are multiple processes and/.or memory spaces involved. The result span will be appended to the original data packet and the new data packet will be returned as a new span by the runtime. The calling code will follow a similar process, but the data will be passed in the runtime in a pointer-free encoding.

Requires merge of #2268 (consider this part 2)

[annagrin]

LGTM!

[1tnguyen]

👍

[schweitzpgi]

I have no idea why it picked up those tpls changes. Total chaos.

[bmhowe23]

I have no idea why it picked up those tpls changes. Total chaos.

When people git pull into their local repo, submodule changes are not typically automatically updated (by git design???). In any case, for future reference, running git submodule status would've revealed that there is a discrepancy in your workspace vs what is committed, and you can simply run git submodule update tpls/Stim to resolve it.

[schweitzpgi]

I have no idea why it picked up those tpls changes. Total chaos.

When people git pull into their local repo, submodule changes are not typically automatically updated (by git design???). In any case, for future reference, running git submodule status would've revealed that there is a discrepancy in your workspace vs what is committed, and you can simply run git submodule update tpls/Stim to resolve it.

I realize that. I saw that it was updated on main and thought I had avoided it. I think it was because I recently changed aliases for this sign-off checking. One landmine for another.