Add docs for new iteration of ent operator import feature

[ncabatoff]

Description

What does this PR do?

TODO only if you're a HashiCorp employee

• Backport Labels: If this fix needs to be backported, use the appropriate backport/ label that matches the desired release branch. Note that in the CE repo, the latest release branch will look like backport/x.x.x, but older release branches will be backport/ent/x.x.x+ent.
  • LTS: If this fixes a critical security vulnerability or severity 1 bug, it will also need to be backported to the current LTS versions of Vault. To ensure this, use all available enterprise labels.
• ENT Breakage: If this PR either 1) removes a public function OR 2) changes the signature
  of a public function, even if that change is in a CE file, double check that
  applying the patch for this PR to the ENT repo and running tests doesn't
  break any tests. Sometimes ENT only tests rely on public functions in CE
  files.
• Jira: If this change has an associated Jira, it's referenced either
  in the PR description, commit message, or branch name.
• RFC: If this change has an associated RFC, please link it in the description.
• ENT PR: If this change has an associated ENT PR, please link it in the
  description. Also, make sure the changelog is in this PR, not in your ENT PR.

[github-actions]

CI Results:
All Go tests succeeded! ✅

[github-actions]

Build Results:
All builds succeeded! ✅

[schavis]

Suggested change

	All the following are optional, in which case the default provider mechanisms are used, e.g.
	a preliminary `az login` can suffice.
	The following parameters are optional. If you leave these parameters unset, for example, by using `az login` before importing, Vault uses the default provider mechanisms.

I wasn't entirely sure what we're trying to say here. Let me know if this isn't an appropriate edit and I'll rework it.

[ncabatoff]

Attempted rewrite in 0f84f9b

[schavis]

Suggested change

	An exact transform allows renaming a secret during import, so that the `from` secret name
	is imported into Vault as a secret named `to`. In the example below, a source secret named
	`foo` will be imported as `foosball`.
	`exact` transforms rename secrets during import so the `from` secret name becomes the `to` secret name. In the following example , takes a source secret named
	`foo` and transforms it to `foosball` during import.

Style correction: write in the active voice

[ncabatoff]

I think "In the following example , takes a source secret named foo and transforms it to foosball during import" doesn't sound quite right, there seems to be a missing subject. I'll try it with "it" as the subject.

[ncabatoff]

Attempted rewrite in 6f7c69c

[schavis]

Suggested change

	- `credentials_file` `(string: "")` - Path to a file containing a vault token. Note that the environment
	variable VAULT_TOKEN can't normally be used for this, since the CLI will use VAULT_TOKEN to authenticate to
	the destination Vault. Exception: it's possible to import from/to the same Vault cluster.
	- `credentials_file` `(string: "")` - Path to a file containing a vault token.
	You must provide `credentials_file` except when importing from/to the same
	Vault cluster because the CLI only uses `VAULT_TOKEN` to authenticate to the
	**destination** Vault instance.

Style correction: write in the active voice

[ncabatoff]

This rewrite loses a bit of fidelity. It's not true that the CLI only uses VAULT_TOKEN for destinations; it will use them for sources as well. But usually that's not what the user will want, because importing from and to the same vault cluster (e.g. from one namespace or mount to another) isn't a common use case. I'll rework it to be active voice.

[ncabatoff]

Attempted rewrite in 6f7c69c