Ensure build.password parameter gets set to generated password for SSH Communicator when no SSH password is set

[matt-richardson]

The problem

When using the new SSH on Windows functionality in 1.4.0, it doesn't appear to be setting build.Password (that is recommend here).

The solution

As discussed in #267 (comment), this change sets the c.Comm.SSHPassword to the generated password, which is (magically, somehow) converted to ${build.Password}.

Tests

_Please include tests. We recommend looking at existing tests as an example. _

I looked to create a new test, but it appears the main scenario is catered for by changing TestConfigUserNameOverride.
The other inverse behaviour is covered by TestConfigShouldBeAbleToOverrideDefaultedValues.

If your PR resolves any open issue(s), please indicate them like this so they will be closed when your PR is merged:

Closes #267

[matt-richardson]

Hi @JenGoldstrich 👋
Any chance of getting this one merged & released? I'm blocked by this issue at the moment.

[JenGoldstrich]

Hey @matt-richardson I'm meeting with a team member this week to understand some context around why the SSH communicator might have been used this way before, and just to make sure this isn't going to break existing Linux users, I will get back to you after I chat with them.

[JenGoldstrich]

I don't think this should be a breaking change for linux builds after chatting with @nywilken, so this looks good to me, thanks for your patience @matt-richardson!

[matt-richardson]

Awesome - thanks @JenGoldstrich!

(don't want to come across as pushy, but) what's your plans around cutting a release? I'm keen to get it into play.

[JenGoldstrich]

https://github.com/hashicorp/packer-plugin-azure/releases/tag/v1.4.1 🚀 yes of course, it's released now! Thanks for this contribution again!

[matt-richardson]

Legend! Thanks!