[BUG] Moc checks for Powershell Remoting are incorrect in assumptions about single-node availability

**Describe the bug**
When you run `Initialize-AksHciNode` or `Set-AksHciConfig`, the Moc cmdlet has to do some stuff to determine if a node has Powershell Remoting enabled:

The first step is to check and enable Powershell Remoting (**Common.psm1**)...

```
function Enable-Remoting
{
<#
.DESCRIPTION
Enables powershell remoting on the local machine.
#>

Write-Status $($GenericLocMessage.comm_ps_remote) -moduleName $global:MocModule

Enable-PSRemoting -Force -Confirm:$false
winrm quickconfig -q -force
}
```

And then after it needs to test it (**Moc.psm1**)...

```
function Test-Remoting
{
<#
.DESCRIPTION
Validate that powershell remoting to a node is working.

.PARAMETER nodeName
The node to remote to.
#>

param (
[String]$nodeName
)

try
{
Invoke-Command -ComputerName $nodeName -ScriptBlock { return $null } -ErrorAction Stop
return $true
} catch {}

return $false
}
```

The problem is this logic assumes that on a single-node system, you can `Invoke-Command` against yourself without it throwing an error and thus you receive a false-negative. This specifically happens when CredSSP hardening is configured and you are _not_ specifying an FQDN to yourself.

As an example, here are screenshots proving that the "raw" commands to enable remoting work fine on the single-node:


`Invoke-Command` from a remote server works fine:


But `Invoke-Command` with shortname to itself fails:


And `Invoke-Command` with FQDN to itself succeeds:


And to no surprise, specifying shortname and a fresh set of creds also works perfectly fine:


Why this happens makes perfect sense if you run `Get-WSManCredSSP`. Only the FQDN of the "local machine" is specified in WSMan for delegating creds:


Other than hacking up the Powershell module to use FQDN, I am unsure how to proceed here.