feat: Optionally allow scoped access to vault token through outputs

[TomNorth]

This PR is to address #352

• Optionally sets vault_token output to the action, so that we can use it in our workflows after authenticating in a scoped fashion.

[hashicorp-cla]

Thank you for your submission! We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept the contribution. Read and sign the agreement

Learn more about why HashiCorp requires a CLA and what the CLA includes

---

11 out of 12 committers have signed the CLA.

• dependabot[bot]
• TomNorth
• tvoran
• benashz
• prizov
• vinay-gopalan
• kevinschoonover
• mldahl
• austingebauer
• maxcoulombe
• ltcarbonell
• Tom North

---

Tom North seems not to be a GitHub user.
You need a GitHub account to be able to sign the CLA. If you already have a GitHub account, please add the email address used for this commit to your account.

_{Have you signed the CLA already but the status is still pending? Recheck it.}

[maxcoulombe]

I know you used the line that already existed below but I believe that it is recommended to use the specific functions from the toolkit to mark a variable or value as sensitive if implementing a reusable action in javascript.

core.setSecret(vaultToken)

Also, dynamic sensitive values created by the action should be marked as secret as close to their instantiation as possible so they are not logged by mistake in between their creation and masking. I think it'd be preferable to move this line right after the moment the token is generated on l.69.

[RichiCoder1]

Yup. If this is emulating this line I believe it's using the manual commmand just because the setSecret function wasn't available at the time.

[maxcoulombe]

One small suggestion and fixing the merge conflicts and I think this would be good to ship. Thanks for taking care of this.

[TomNorth]

Sorry @maxcoulombe I borked my fork trying to sort this out and accidentally closed this PR. I have reopened another one. Unfortunately the CLA is failing because some commits were made with an email address associated with my old workplace, but the new one is added, you can see signed as TomNorth.

[maxcoulombe]

@TomNorth Thanks for the fixes and reopening the PR. I'm confirming internally if I can merge the PR #441 even with one signature missing on the CLA due to the circumstances you described.