Proposal: add span.id to transactions, rename parent.id

https://github.com/elastic/ecs/issues/998 highlights some issues with the fields we use in APM. In particular:

- the meaning of `parent.id` is unclear from its name
- the relationship between transactions and spans is unclear

For Elastic APM agents, spans always have an associated `transaction.id`. This is not the case when translating OpenTelemetry data to Elastic APM, as OpenTelemetry does not have a concept of "entry-point spans". As a result, not all spans have an associated `transaction.id`, and if OpenTelemetry data is to be a first-class citizen in Elastic APM, the UI cannot make any assumptions about `transaction.id` being present in spans.

We already consider and treat transactions as a special sort of span (entry-point spans). Transactions and spans share a significant amount of overlap: trace IDs, timestamp, duration, outcome. I propose a minor change to our data model, moving towards unifying transactions and spans:

- add a `span.id` to transaction documents. As an implementation detail, this could just be an alias to `transaction.id`.
- rename `parent.id` to `span.parent_id`; this now always refers to a `span.id`, never `transaction.id`.
- `transaction.id` is used only for identifying spans that are part of the same local sub-tree. This field becomes optional.

Thus in terms of IDs, transactions *are* effectively spans. There are still other important differences that we would later need to change if we want to completely unify transactions and spans, such as `transaction.type`, `transaction.name`, etc.

**Question**: what remaining benefits are there to including `transaction.id` in span documents, or in transaction documents for that matter?