ProjectStartedEvents for already-run projects have bad IDs

[rainersigwald]

Repro projects: PSE_invalid_ids.zip

Build with dotnet msbuild entry.proj -bl.

Compare the log events for the first (real) ProjectStartedEventArgs for for project1:

"BuildEventContext": {
  "EvaluationId": 36,
  "NodeId": 2,
  "TargetId": -1,
  "ProjectContextId": 36,
  "TaskId": -1,
  "ProjectInstanceId": 4,
  "SubmissionId": 0,
  "BuildRequestId": -2001796771
}

With the ones emitted the second time (when it's satisfied already and we don't need to do real work in the project):

"BuildEventContext": {
  "EvaluationId": -1,
  "NodeId": 1,
  "TargetId": -1,
  "ProjectContextId": 103,
  "TaskId": -1,
  "ProjectInstanceId": 4,
  "SubmissionId": 0,
  "BuildRequestId": -2064531812
}

NodeId is 1 when it should be 2.

EvaluationId is invalid when it should be specified.

(@baronfel and @jaredpar and I have been looking at related areas--this was discovered when Jared started asserting when a specific ProjectInstanceId appeared to move between nodes.)

[baronfel]

The mismatched node ids are coming from the second message being generated from the context of the first node - even though the first node knows from the BuildRequestConfiguration that was matched that the Project results are on another node. I've been able to fix that in #12946 now, but the core problem I'm seeing is still that of evaluation ids - the BuildRequestConfiguration type is used both local to a node (and that I have persisting round-trip now), but also when a node finishes evaluation to tell the central node about configurations the worker node knows - we need the worker node to also be able to send the eval ID somehow so that the central node can also have this information. If we have that then we should be able to keep the important pieces of data mirrored:

• nodeId
• submissionId
• projectInstanceId (aka configuration Id)
• evaluationId

[baronfel]

OK! Evaluation ids are now flowing across BuildResults too, so this should be solved by my linked PR.