Fix Touch race condition on first run with parallel MSBuild nodes

[MattKotsenas]

Description

When multiple MSBuild nodes run dotnet husky install concurrently on first checkout (e.g., via Directory.Build.targets), the mutex losers skip the install but the Touch task still tries to create install.stamp in the .husky/_/ directory. Since that directory hasn't been created yet (the winner is still working), this fails with:

error MSB3371: The file ".husky/_/install.stamp" cannot be created.
Could not find a part of the path '.husky/_/install.stamp'.

Who's impacted:

• Users who adopted the new incremental target (v0.9.0 via dotnet husky attach or docs snippet)
• In a solution with multiple projects (where MSBuild runs parallel restore)
• Only on first build after a fresh checkout (before .husky/_/ exists)

Not impacted:

• Users with the old target (no Touch task)
• Single-project solutions (no parallelism)
• Any build after the first successful one (directory exists, Touch condition passes)

Fixes #155

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist

• I have performed a self-review of my code
• I have added tests that prove my fix is effective or that my feature works
• I have made corresponding changes to the documentation
• I have commented my code, particularly in hard-to-understand areas
• New and existing unit tests pass locally with my changes
• I did test corresponding changes on Windows
• I did test corresponding changes on Linux
• I did test corresponding changes on Mac

[what-the-diff]

PR Summary

• Update on automated checks for Touch element
  The automate.md file has been revised to include a check for the existence of a certain directory (.husky/_) before running the Touch element. It provides additional safety measures to ensure all necessary prerequisites are met before the execution of the task.

• New condition and attributes added to submodule handling
  Changes in submodules.md include the newly added condition for the Touch element that was added to automate.md. Moreover, inputs and outputs attributes have been defined for the husky Target to clearly segregate incoming data and resultant findings.

• Availability check of directory before setting conditions
  In AttachCommand.cs, conditions for running the Touch element are now assigned based on the existence of the directory (.husky/). This assures that the command will only be activated if the vital directory is present.

• Changes in the sequencing of the Husky Target
  The update in Husky.csproj modifies the sequence of when the husky Target is called, moving it from before the targets to after them. The requirement of the existence of .husky/_ was also applied for Touch element validation, making sure that the task will be performed only if the directory is available.

• Test adjustments to verify condition setting
  With the modifications in AttachCommandTests.cs, tests have been adjusted to confirm that the condition attribute for the Touch element correctly verifies the existence of the directory before running. This helps in maintaining code accuracy and efficacy.

[MattKotsenas]

/cc @alirezanet, I found a bug in the new target (sorry 😥). It's unlikely to impact many existing users, but given that we just shipped it, wanted to flag for fast follow up.

Let me know if there's anything I can do to help.

[alirezanet]

Thanks for testing it
LGTM, but now I'm thinking it might be hard for users to adjust the file paths correctly if they want to do it manually.
if you had time please investigate to see if there is anyway to reuese the WorkingDirectory somehow in other elements. what I'm thinking is to define the husky working directory once and reuse it for all of these paths. so we don't end up with multiple paths like ../../.husky/_
but yeah if you think is not possible or it is time consuming is better to merge this PR first and investigate later.

[MattKotsenas]

If it's ok with you, want to merge this and I'll follow up?

The reason I didn't do it initially is because it's also in the Inputs and Outputs, so I can't define any base property inside the target to reuse.