Use an advisory lock to co-ordinate access to git checkout repos

[mitchmindtree]

This introduces an advisory lock around the re-usable git checkout repo directories.

Closes #2603, #3484.

Unfortunately, it's a little tricky to reliably test this from this project repository as doing so requires creating a test project with one or more git dependencies. We can't reliably add git dependencies (that point to external repos) to projects within this repo as the dependency would necessarily be at least one commit of forc behind, and as a result it's likely that these dependencies would break at some point in the future, e.g. next time forc makes some breaking change.

@segfault-magnet, @hal3e would you mind testing this branch in your use-case mentioned in #2603 to make sure we've covered the issue?

Edit: I've managed to test this locally by adding some long sleeps immediately after acquiring the lock guard, and then spinning up multiple processes of forc locally to build a toy project with multiple git dependencies. All appears to work fine, with each process blocking and waiting its turn for access to the checkout repo.

[spiral-ladder]

The way I was testing it was to fork both sway and fuels-rs, update fuels-rs to build with the concurrent flag and allow manual workflow triggers and use my fork with the lock changes within the fuels-rs GitHub workflow instead. FWIW when I (unsuccessfully) tackled #3484, I tested my fork on my machine which works locally but fails on the CI, so results might differ there.

[kayagokalp]

utACK

[spiral-ladder]

I went ahead and used my personal repo setups to check out your branch and tested it and it works: https://github.com/bingcicle/fuels-rs/actions/runs/3702649777/jobs/6273211503#step:8:236

[hal3e]

I want to confirm that this works perfectly! Thanks a lot!!! ❤️