Add several IOF attributes

[rhc54]

In the course of implementing the IO forwarding support, we identified
several attributes deemed valuable by users. These primarily control
the output format and target location (e.g., files instead of terminal),
and whether the output should be generated locally or simply relayed
to another location (e.g., a tool) for handling.

This RFC contains the definitions and indicates the APIs where those
attributes can/should be passed.

Signed-off-by: Ralph Castain [email protected]

[rhc54]

Please use emoji reactions ON THIS COMMENT to indicate your position on this proposal.

You do not need to vote on every proposal
If you have no opinion, don't vote - that is also useful data
If you've already commented on this issue, please still vote so
we know your current thoughts
Not all proposals solve exactly the same problem, so we may end
up accepting proposals that appear to have some overlap
This is not a binding majority-rule vote, but it will be a very
significant input into the corresponding ASC decision.

Here are the meanings for the emojis:

Hooray or Rocket: I support this so strongly that I
want to be an advocate for it
Heart: I think this is an ideal solution
Thumbs up: I'd be happy with this solution
Confused: I'd rather we not do this, but I can tolerate it
Thumbs down: I'd be actively unhappy, and may even consider
other technologies instead
If you want to explain in more detail, feel free to add another
comment, but please also vote on this comment.

[naughtont3]

I think the “%r” and “%n” in the PR need to be escaped to avoid having LaTeX bomb, e.g., \code{%r}

[jjhursey]

PMIx ASC 1Q 2022

• Passed the first vote: 11 yes / 0 no / 0 abstain
• This is can be merged into main/v5 and v4 branches once conflicts are addressed (I'll work on that)

[jjhursey]

Editorial: Rebased the reference branch without text changes to prepare to merge. Resolve a couple of minor text placement merge/rebase conflicts in Chap_API_Tools.tex and Chap_API_Server.tex