Add methods in Ansible Vault utilities to find the ansible-vault executable

[sleberknight]

The VaultEncryptionHelperIntegrationTest contains code that finds the location of the ansible-vault executable using which. If it does not find it, then it falls back to "well known" locations for macOS (assuming Homebrew installation) and Linux.

In our new environments, ansible-vault is installed via pip, so the location is ~/.pip/bin/ansible-vault. Our existing service code (and specifically the "core service" library) assumes the standard Linux location of /usr/bin/ansible-vault, so the code obviously fails.

Instead, it would be better to use the strategy used in the test, i.e. first try finding it via which and then maybe falling back based on OS like the test does. This could be a static method in VaultEncryptionHelper or maybe in VaultConfiguration. For example,

// The value returned by this may or may not exist, i.e. if "which" returns nothing, then
// the fallback value might not actually exist on the filesystem. Maybe don't have this
// at all, since it would force callers to check for existence.
public static String whichAnsibleVaultOrFallback() { ... }

// This could use "which", and if that fails, then attempt several fallback locations based on OS
public static Optional<String> whichAnsibleVault() { ... }

These should be implemented using the which method which will be added to the kiwi process-related utilities in #945.

Other considerations include:

• Should these go in VaultConfiguration, VaultEncryptionHelper, or somewhere else?
• Should they be static methods only, or also provide instance methods analogous to ProcessHelper?
• How should the fallback values be determined? VaultEncryptionHelperIntegrationTest assumes Homebrew-based installation on macOS (and the location is pre-Silicon so /usr/local instead of /opt/homebrew), and assumes /usr/bin on Linux.
• If we have a list of fallbacks, maybe each should be checked to see if they exist, and only return a value that actually exists
• An alternative fallback could include having the caller supply their own location as a String or as a Supplier<String>, or both

This originated from discussion #944

[sleberknight]

Here are some "well-known" locations that we can try as fallbacks. These are not official locations but are just a few locations I've found using various installation methods and operating systems. And of course, package managers often let you specify a different installation location, etc.

OS	Installation method	Location
macOS (Intel)	Homebrew	/usr/local/bin/ansible-vault
macOS (Applie Silicon)	Homebrew	/opt/homebrew (TODO: get rest of path when on a mac)
Linux	Homebrew	/home/linuxbrew/.linuxbrew/bin/ansible-vault
Linux	yum	/bin/ansible-vault
Linux	pip	~/.pip/bin/ansible-vault

Since there is so much variation, I am thinking maybe we should just not even try to have "standard" fallback locations at all. Though, I am OK with providing an option to allow callers to specify a fallback location and/or a supplier of fallback location.

[sleberknight]

Actually, if we return Optional there is little value in adding overloads that accept a fallback, since Optional already lets you do that easily using orElse, orElseGet, etc.