`ssh_private_key_file` used for both droplet creation and subsequent connection

#### Overview of the Issue

Previously I had an issue when providing a private SSH key to connect to my newly created droplet: #19

The fix provided in #20 and shipped with `v1.0.1` fixed my issue and I've been using that version ever since.

Now I'm (finally) upgrading to a more recent version and my existing configuration results in a different error.

The private key specified in my config is being used as both the root key when creating the droplet and the ssh key when connecting as a user (which may not be root) to provision the droplet.

In my case, I have a user named `deploy` that already exists on the base image that I want to connect as. Giving `root` the same key as `deploy` is no bueno.

I noticed this because I have that key added to DO already separately, and when trying to create the root key it fails since there's a duplicate.

I believe this bug emerged in the following commit: https://github.com/digitalocean/packer-plugin-digitalocean/commit/0462cbc5d32f1013f2c067116bb836a2ef19030e

Versions of the plugin pre-1.2.0 work as expected.

My desired functionality is to be able to specify the root key and the communicator key separately. If I don't specify a root key then the plugin should generate a temporary one for me, but then connect using the supplied communicator user/key.

#### Reproduction Steps

1. Create a keypair on the host where you're running packer.
2. Add that key to Digital Ocean.
3. Create a packer buildfile that specifies the private key file but _not_ the key ID from Digital Ocean
4. Run `packer build`
5. Observe the output (example below)

### Plugin and Packer version

Packer: 1.9.4
Plugin: 1.2.0 and up

### Simplified Packer Buildfile
```
variable "deploy_private_key_file" {
type = string
default = null
}

variable "digital_ocean_application_image_id" {
type = string
default = null
}

build {
name = "application_server"
source "source.digitalocean.default" {
image = var.digital_ocean_application_image_id
snapshot_name = "backend_server"
snapshot_regions = ["tor1", "nyc3"]
ssh_username = "deploy"
ssh_private_key_file = var.deploy_private_key_file
}
}
```

### Operating system and Environment details

MacOS 13.6.3

### Log Fragments and crash.log files

Full plugin output from my packer run:
```
Debug mode enabled. Builds will not be parallelized.
application_server.digitalocean.default: output will be in this color.

==> application_server.digitalocean.default: Using existing SSH private key
==> application_server.digitalocean.default: Pausing after run of step 'StepSSHKeyGen'. Press enter to continue.
==> application_server.digitalocean.default: Pausing after run of step 'nullStep'. Press enter to continue.
==> application_server.digitalocean.default: Importing SSH public key...
==> application_server.digitalocean.default: Error creating temporary SSH key: POST https://api.digitalocean.com/v2/account/keys: 422 (request "e362b52b-ac39-4c99-b14f-cb6bf0804dc0") SSH Key is already in use on your account
==> application_server.digitalocean.default: Pausing before cleanup of step 'nullStep'. Press enter to continue.
==> application_server.digitalocean.default: Pausing before cleanup of step 'StepSSHKeyGen'. Press enter to continue.
Build 'application_server.digitalocean.default' errored after 20 seconds 184 milliseconds: Error creating temporary SSH key: POST https://api.digitalocean.com/v2/account/keys: 422 (request "e362b52b-ac39-4c99-b14f-cb6bf0804dc0") SSH Key is already in use on your account
```

Start with the plugin's handling of ssh_private_key_file and the StepSSHKeyGen entry point, then reproduce the failure using the simplified Packer buildfile and the versions described. Done means the root DigitalOcean key and communicator user/key can be specified separately, with a temporary root key generated when no root key is supplied, without attempting to import a duplicate key.

Written by the indexing model from the issue text.