Remove unnecessary lock in TerminalLogger.UpdateNodeStatus

[dfederm]

This is a minor perf improvement.

In particular when using the project cache with a high cache rate (thus spamming ProjectFinished events), this lock is taking ~6% of the CPU for the process due to contention. That's a lower bound though because I'm seeing other methods which do take the lock also suffer from high contention (eg ThreadProc also takes ~6% CPU), so removing the lock from UpdateNodeStatus is likely to reduce contention there as well.

This lock isn't necessary since this operation is a simple object replacement in an array. Other similar operations also don't take a lock, (See the write in ProjectStarted and the read in MessageRaised) which proves that it's not required.

[JanKrivanek]

Looks good - the lock seems to be used to guard the terminal access (rather then write access or sequentialization of order).

If the contention is so high - we might want to consider offloading the updates to single UI processing thread (or do a mixed solution via updating sinchronously only if Monitor.TryEnter is successful without timeout and otherwise queue the request for a UI processing thread).