Add paragraph about usage of parent-child relationship

[joaopgrassi]

Fixes #1282

Changes

Adds a paragraph mentioning the possibility to use the message creation context as a parent of "Process" spans, to achieve a more traditional parent-child trace structure.

Merge requirement checklist

• CONTRIBUTING.md guidelines followed.
• Change log entry added, according to the guidelines in When to add a changelog entry.
  • If your PR does not need a change log, start the PR title with [chore]
• schema-next.yaml updated with changes to existing conventions.

[lmolkova]

LGTM, suggesting to add a bit more guidance for parent case

[lmolkova]

I'm suggesting to add a bit of additional guidance around the ambient context and defaults.

Suggested change

	parent-child relationship between producer and consumer(s).
	parent-child relationship between producer and consumer(s). Instrumentations SHOULD document whether they use message creation context as a parent for "Process" spans and MAY provide configuration option allowing users to control this behavior.
	It's NOT RECOMMENDED to use message creation context as a parent for "Process" span (by default) if processing usually happens in the scope of another span.
	If instrumentation uses message creation context as a parent on "Process" span in the scope of another valid ambient context, it SHOULD set the ambient context as a link on "Process" span to preserve correlation between message processing and that context.
	For example, a messaging broker pushes messages to consumers over HTTP and a consumer application has HTTP server and messaging instrumentations enabled. The messaging instrumentation would create "Process" span following one of these possible approaches:
	- "Process" span is a child of HTTP server span context and has a link to message creation context. This is the default behavior for this instrumentation.
	- "Process" span is a child of message creation context and has two links: one to message creation context and another one to HTTP server span context. This is opt-in behavior.

LMK what you think.

Maybe we can also put it all into a new section like "Using message context as a parent for "Process" spans" so it appears in the TOC?

[joaopgrassi]

I was thinking the same, but to add new headers for Receive spans and Process inside the Consumer spans section. Right now they are all together and I find it a bit hard to follow.

That didn't look good. Nope 😅

I like what you suggested Using message context as a parent for "Process" spans" but I feel maybe it's not so clear for general users? I want to come up with something that easily highlights "how to get a parent-child trace"