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

### 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 https://github.com/dotnet/msbuild/pull/12946 for a detailed treatment.

### Versions & Configurations

_No response_