Optional code quality linter rule + code fix to clarify operator precedence with parentheses

Technically the following are all valid, but difficult to understand or catch bugs in if you don't have an understanding of Bicep's exact operator precedence rules (I'm betting 99% of people, myself included, don't):
```bicep
var foo = 1 + 2 / 3
var bar = {
...cond ? { prop: 1 } : {}
}
var baz = cond1 ? cond2 ? 'abc' : 'def' : 'ghi'
var qux = cond ? null : 'notnull' ?? 'notnull'
```

My personal code style would be to add parentheses (even if technically unnecessary) to make it easy for others to understand:
```bicep
var foo = 1 + (2 / 3)
var bar = {
...(cond ? { prop: 1 } : {})
}
var baz = cond1 ? (cond2 ? 'abc' : 'def') : 'ghi'
var qux = cond ? null : ('notnull' ?? 'notnull')
```

Use the four Bicep examples as the behavioral starting point, then locate the linter and code-fix entry points that handle operator precedence. Check how an optional rule is configured and how existing fixes are tested. Done means the rule identifies the shown ambiguous expressions, offers parentheses fixes, and leaves already-clear expressions unchanged.

Written by the indexing model from the issue text.