Include API Version in input/state

[EronWright]

Overview

Closes #3766

This PR is aimed at improving the experience around api versions, e.g. when upgrading a resource to a new api version. Note that major version upgrades of this provider tend to change the 'default' versions of many resources.

1. Show some diff output and and actually update the resource state when the api version of a resource is being changed.
2. Record the actual api version that was used in create/update/read, to inform subsequent operations.

In 2.x mode, the provider simply records the actual azureApiVersion as an output property, but doesn't expose it at the SDK level. The rationale is to have the information available in "old state" +before+ the major upgrade is performed; this allows the provider to avoid a spurious diff and to make fewer update calls during the major upgrade.

In 3.x mode, the provider introduces a new azureApiVersion input property, with a constant value. The input property is NOT added to the resource args; it is always defaulted in Check. In the future, a true input property might be added to support overrides. The purpose of having a checked input is to produce a diff when the API version has changed (for whatever reason). This leads to an update call against the new API version of the resource, to validate the inputs and refresh the state.

The output property that was added to state in 2.x is fully exposed in 3.x at the SDK level.

Migration

In a migration case, the old azureApiVersion isn't yet known, and this may lead to a spurious (though harmless) update because the value goes from empty to known. We mitigate this by reading azureApiVersion from old state during Diff. The recommended migration flow is:

1. User upgrades to the latest 2.x with pulumi up (to update the provider version) followed by pulumi refresh (to update the resource's state. Now there's an azureApiVersion in state for each 2.x resource.
2. User upgrades to 3.0 with pulumi up, and the provider compares old state to new input to see whether the api version is actually changing, e.g. due to a change to the "default version" of a resource.

For example, here's the impact to the state file after completing the migration as described. We see two affected resources: a resource group and a storage account, with the latter undergoing a change to the 'default' API version.

Invokes

Another aspect to this PR is the azureApiVersion output property and supporting the getFoo functions. The code generator must be careful to apply the output property to the resource type (as represented by isTopLevel), not to functions. There is, however, a special "get" function where it does make sense to return the azureApiVersion.

[EronWright]

Replaced by #4015