[Feature Request]: Align parameter files naming and scenarios

[eriqua]

Description

Align on the different use cases we want to cover in our module tests and reflect that in the parameter naming convention. For instance:

• modules covering multiple services should cover all test scenarios
  • e.g. cognitive services cover both speech and face services. parameter files should cover both use cases, hence include speech.parameters.json and face.parameters.json
• always include a min.parameters.json to cover only required parameters. For modules covering multiple services this could be duplicated if different services lead to different implementations.
  • e.g. cognitive services cover both speech and face services. parameter files should cover both use cases, hence include speech.min.parameters.json and face.min.parameters.json
• all modules providing cmk functionality should include a encr.parameters.json (or cmk.parameters.json). For modules covering multiple services this could be duplicated if different services lead to different implementations.

  Discussion needed: we could go for either a "always use encr.parameters.json" for consistency and to clearly show shorter specific examples in the readme or "use it only if required due to incompatibility with other settings" to instead try to include all possible features in the main parameters.json. The latter approach would probably be preferable considering the new dependencies approach. In either case update the Wiki as needed.

• all modules providing networking functionalities ahould include a net.parameters.json (or similar). For modules covering multiple services this could be duplicated if different services lead to different implementations.

  Discussion needed: same as above.

---

Update: this is now related to main.test.bicep wrapper modules

[eriqua]

Related to #401 which would be the implementation out of this discussion. I'd also propose to rename current max.parameters.json (analysys services and API management) to parameters.json to have consistency throughout the repo for the main test file. This main test file is a good candidate to be used for the public Bicep registry contribution, so it makes sense to have a consistent naming for that one.

[rahalan]

Wiki also needs to be updated