Add version and downsert

[Moon1706]

This PR appends 2 additional fields: version and downsert.
The version variable allows you to manage the target version of Pulumi. Default value is ^3.
In turn, downsert variable in combination with destroy command removes Pulumi stack. Default value is undefined.
PS: added checking downsert in the Promise impossible, because after this we use Stack variable a few times.

[RobbieMcKinstry]

Hi @Moon1706 Thanks for your contribution. 👏🏻
However, I'm seeing the version selection is currently until development in #661 . I'd like to give first-time contributors an opportunity to get their contributions merged in and celebrated, especially since that PR pre-dates this one.

Also, regarding downsert, I recently posited in #681 that it might be preferable to add a pulumi stack command instead of an option on destroy. Would you add your thoughts to that issue? I'd like to hear what you have to say about that solution. :)

In the future, would you please submit separate PRs for individual features? It's very unlikely we merge a PR for more than 1 feature at a time. This helps reduce the maintenance burden, helps us to review PRs quickly, and reduces the likelihood of introducing regressions.

Thanks again for your active participation in our OSS community.

[Moon1706]

@RobbieMcKinstry
Okay. It's a draft from my own Pulumi Action and I wanna rewrite this code.
About conception. Mmm, that's a tough question. Probably, we can realize 3 various scenarios:

1. We'll just append downsert option field. Easy, but in perspective we flood code with if section.
2. We'll create an additional command stack rm. That's string from official Pulumi command. So, in this case, we should or realize of command, supported by stack or just make only one action for stack rm, but it can confuse users.
3. Rename remove stack command to rm. I reckon it's a bad idea, because this doen't documented on the Pulumi site.

To recap, I think the first case is the best, but I opened for another suggestion.

[RobbieMcKinstry]

#681 (comment)
I think I'm happy to move forward with adding a stack command with an args subcommand. :)

[Moon1706]

@RobbieMcKinstry
Sorry for a long answer, a lot of work. I've thought about this suggestion and unfortunately I don't agree that's a good idea. Now, this GHA supports a declarative approach with something like CRUD requests. If we'll move to the command and args we can get strange nonsense behavior, when a person'll execute many actions like iterative commands. And that's uncorrelated with the GHA conception. But if you really wanna realize this, I can suggest this NPM package to execute Pulumi commands.

[RobbieMcKinstry]

Thanks for the suggestion! I haven't seen this package before. I'll take a look.

I do agree that the args escape hatch is undesirable because it turns the action from declarative to imperative.
I just worry the pulumi CLI has many commands and subcommands, and supporting every possible execution of these in a declarative format will take a long time and result in a large amount of code.

I'll give it some more thought! Maybe it's enough to support only the subcommands users request once they request them, slowing the complexity growth until it's needed.

[Moon1706]

@RobbieMcKinstry
Yes, please. And I have also additional suggestion. That's strange, but maybe interesting. We can create advanced configuration with Yaml structure. Like in config-map field. User'll add config with Yaml structure, we'll parse config and execute Pulumi with settings. In config Yaml we can organize 2 section: declarative and imperative and user'll choose how he or she wanna start Pulumi command.
Little disclaimer, that's just an idea. I don't see that someone makes GHA with this style.

[RobbieMcKinstry]

Quick follow up:
The merge of #661 adds the ability to select the Pulumi version as an action input.
This feature will be released later this week in a new minor release