Fix docker-machine detail races

What does this MR do?

Fixes concurrency races accessing machineDetails' fields.

Why was this MR needed?

• Several -race unit tests where broken.
• A Windows test, that for some reason was more susceptible to races where we were checking state before it has been updated (some of the removal is done in a go routine).

Locking and unlocking like this is far from ideal, but larger refactors are probably even more susceptible to us introducing a bug.

What's the best way to test this MR?

• Check -race unit tests with another Pipeline. The docker machine executor ones should now be eliminated.
• The Windows test TestMachineIdleLimits should be fixed.

To review:

• Ensure that all details fields have a lock. The only one that doesn't need one is Name, as it's only read from after creation.
• Search for every instance of details.Lock():
  • Ensure that all functions called within the lock don't have a further lock to avoid deadlocks. I've checked several times that this is the case.
  • Ensure all of the functions called within a lock are not called anywhere outside of the lock.
• Where m.lock has been replaced with details.Lock, ensure that anything m.lock could have been protecting is still protected.

What are the relevant issue numbers?

#30835 (closed)