Logger BuildEventContexts drop 'parent' context associations in certain use cases

[baronfel]

Issue Description

MSBuild's logging infrastructure used multiple constructor overloads that made it easy to accidentally omit important ID values, and that BuildResult objects weren't preserving evaluation context when sent between nodes in distributed builds.

Problem Statement

BuildEventContext Construction Issues

MSBuild's BuildEventContext class had multiple public constructors that made it easy to accidentally drop ID values when creating derived contexts. This was particularly problematic for:

1. Evaluation ID loss - Critical for correlating build events with specific project evaluations
2. Inconsistent context chains - Parent contexts losing data when creating child contexts
3. Performance overhead - Multiple heap allocations when chaining context updates
4. Error-prone API - Easy to pass wrong parameters or omit values entirely

Distributed Build Evaluation ID Loss

In MSBuild's distributed build architecture, worker nodes evaluate and build projects independently, but the central BuildManager wasn't receiving complete evaluation context. The issues were:

1. Missing serialization - BuildResult objects weren't serializing evaluation IDs during node communication
2. Incomplete worker population - Worker nodes weren't setting evaluation IDs in results before sending to central node
3. Central state inconsistency - BuildRequestConfiguration objects losing track of which evaluation generated each result
4. Broken traceability - Central node unable to correlate results with specific project evaluations

Steps to Reproduce

Discovered while @jaredpar was trying to create automated tooling to track certain build events via these linkages.

Expected Behavior

Every BuildEventContext should be logically derived from a parent context, and contain all of the linkage data that's logically 'shared' with that parent context. Examples:

• node contexts are top-level
• submission contexts may be top-level, but may be derived from a node context
• evaluation contexts must be associated with a node and submission
• and so on

Actual Behavior

Several logging locations that create buildeventcontexts from whole cloth miss one or more logically-required parent scope data fields.

Analysis

See #12946 for a detailed treatment.

Versions & Configurations

No response