Update data guideline: Parameters and parameter object features

[Elchi3]

This data guideline needs to be updated: https://github.com/mdn/browser-compat-data/blob/main/docs/data-guidelines/README.md#parameters-and-parameter-object-features

See the discussion in #29739 (comment) as well as #29451 which used a nested structure.

In today's BCD call, we agreed that nesting structures are better.

• Better validation/linting is in place if features are properly nested.
• MDN rendering for deeply nested features is AFAIK not a problem anymore.

So the guidelines should reflect that and present how to nest parameters keys correctly. It will probably look like this:

• someMethod
  • options_parameter
    • propA
    • propB
    • propC_options_parameter (we don't need the longer names)

We should be using names from the specification (there are different names for the object parameters like "option", "init", "configuration")

[hamishwillee]

Eventually you may get to allowed values for a particular property. For #29739 you'd note there is no indicator that a prop is a prop - it's name is just keySystemConfiguration or type.
However I did indicate that the allowed value is an option - webrtc_option

- "decodingInfo": {
  - "configuration_parameter": { #param
    - "keySystemConfiguration": {  # prop
    - "type":  # prop
      - "webrtc_option": { # Allowed value of an option.

Could you clarify that in the object schema too (i.e. how I address this case "fully".

[Elchi3]

Yes, we'll have to define this. What you've done in the PR seems sensible to me.
mdn/content has page types, and this is another case why BCD types (#3496) would be useful, so we could say "this is a property, therefore these rules apply".