hooks: Refactor directory locks and hash generation

Currently the RestoreCustomHooks RPC uses safe.LockingDirectory to prevent concurrent modification of a repository custom_hooks directory. When the custom_hooks directory is locked a .lock file is created inside and and subsequent calls to Lock() will fail until the directory is unlocked.

In future commits, having this .lock file exist inside the custom_hooks directory will result in vote hashes being constructed with the lock file. Also it will make atomic directory swap operations vulnerable to concurrent modification.

To remediate this, indstead of creating a .lock file in the custom_hooks directory, a named lock file is created inside the repository directory. By giving the lock a name the lock is associated with the custom_hooks directory without existing inside of it.

Also...

Currently the RestoreCustomHooks RPC generates a vote hash for a transaction by using the tar archive it receives as input. This means that if extraction of the archive generates a differing result across nodes, the generated vote hash will still be the same since it is based on the preimage of the contents.

This change refactors vote hash generation for custom hooks to instead walk the extracted custom_hooks directory and hash the file name, permissions, and data. This ensures the vote being cast in the transaction reflects the actual state of the hooks in the repository.