301-sql-alwayson-md-ilb-zones fails when re-deployed

[301-sql-alwayson-md-ilb-zones](https://github.com/Azure/azure-quickstart-templates/tree/master/301-sql-alwayson-md-ilb-zones)

### Issue Details
When re-running the deployment, it fails if it previously got as far as configuring the Storage Spaces for the F:\ drive. This is because both PrepSQLAO.ps1 and ConfigSQLAO.ps1 contain the below code, which always returns the next free drive letter.

```
#Finding the next avaiable disk letter for Add disk
$NewDiskLetter = ls function:[f-z]: -n | ?{ !(test-path $_) } | select -First 1
$NextAvailableDiskLetter = $NewDiskLetter[0]
```

The above returns F the first time it's run, then G the second time. When this is passed into **xSqlCreateVirtualDataDisk NewVirtualDisk** it causes **Test-TargetResource** to return false (correctly, because there is no G:\ drive) which in turn causes **Set-TargetResource** to fail because no additional disks have been added so there are none free with which to create the new Storage Space.

### Repro steps
1. Deploy 301-sql-alwayson-md-ilb-zones as instructed
2. Once completed, re-deploy again

Start with PrepSQLAO.ps1 and ConfigSQLAO.ps1, then trace how the selected drive letter is passed to xSqlCreateVirtualDataDisk NewVirtualDisk. Reproduce the issue by deploying 301-sql-alwayson-md-ilb-zones and re-deploying after Storage Spaces config reaches the F:\ drive. Done means the second deployment succeeds without requiring nonexistent additional disks.

Written by the indexing model from the issue text.