Consistently implement (and document) API design guidelines for Input/Output properties

[lukehoban]

We've been inconsistent on where @pulumi/cloud APIs accept and/or return T vs. Computed<T> vs. ComputedValue<T>.

Once the Input<T>/Output<T> changes land, we should do a pass over @pulumi/cloud and implement our API design guidelines consistenty (and the document those guidelines for other library authors).

We generally expect the API design guideline to be along the lines of:

All inputs that do currently, or may in the future, flow into inputs of resource creation must be pulumi.Input<T>. For structured data, like objects of arrays, pulumi.Input should be as far out on the type as possible - so preferring pulumi.Input<string[]> to pulumi.Input<string>[] where possible to allow the largest number of potential callers. There may be limits on this, due to the need to enumerate the array promptly at deployment time to create new resources - and in these cases it is correct to use the latter type above. All return values or output properties which can potentially flow from the outputs of resource creation must be pulumi.Output<T>.