Considerations for revisiting parameters

Parameters have a bunch of usability and ergonomics issues today that we should consider when we revisit them:

- Parameters are currently hidden in the dashboard by default. Since 9.4 you can view hidden resources which shows parameters but they have a state of "Unknown" and their values aren't shown in the dashboard resource details.
- No nice APIs for adding a generated password parameter to the model. Instead one needs to discovery and call `ParameterResourceBuilderExtensions.CreateDefaultPasswordParameter` then pass the result into `builder.AddResource` which results in the parameter not being hidden. We should likely have an overload of `builder.AddParameter` or something like `builder.AddPasswordParameter`
- It's too easy to access the value of parameter resources from code thanks to the `Value` property in ways which aren't compatible with publishing, and there's nothing that warns you. We should consider making the `Value` property throw when in publish mode, or even getting rid of the property and forcing other call sites to support accepting the parameters in a first-class way, etc.
- No way to specify the type of value expected in a parameter or validate the value. We have cases where we validate non-parameter values in run mode and throw if they're invalid, but if you get the value via a parameter the value isn't validated at all. We should consider adding support for known parameter data types, e.g. integer, URI, connection string, etc., and that preserve in the model during publish. Or even just being able to specify a description for a parameter so that it can be included in the manifest, etc.