Fail or verbosely warn about SSH key permissions when running Update-AksHci, Get-AksHciLogs, Get-MocLogs, etc

Any Powershell cmdlet that requires SSH access will attempt to use the keys located in `(Get-AksHciConfig).Moc.sshPrivateKey`

However, [as discussed in this Docs page](https://docs.microsoft.com/en-us/azure-stack/aks-hci/set-multiple-administrators), if a _different user_ is attempting to run commands such as `Get-AksHciLogs` or `Update-AksHci`, it will "fail" in some shape or form due to permissions not being set for that user on the key:


Until a better solution is figured out for multiple Windows Users managing an AKS-HCI cluster, **_can we please perform a precheck on the SSH keys using information returned from_** `Get-Acl` ?

Side note... I am curious about the number of Customer Support tickets opened that are a result of silly things like this. I know I was recently burned by this and the only indication this was the problem was me digging thru Docs pages that mention it in passing. The cmdlets can def be improved to catch or warn the user first.

Review the SSH-dependent cmdlets named in the issue, including Update-AksHci, Get-AksHciLogs, and Get-MocLogs, along with the key path from (Get-AksHciConfig).Moc.sshPrivateKey. Start by examining how Get-Acl reports access to that key. Done means these cmdlets precheck permissions and fail or warn verbosely when the current user cannot use the key.

Written by the indexing model from the issue text.