Add typeApplications option for restricted functions
Revives the idea from #1667 (closed stale) for issue #1637: let a function restriction require or forbid **visible type applications**, so a silent change to an inferred type can't change behaviour unnoticed.
## Config
```yaml
- functions:
- {name: show, typeApplications: required} # >= 1 type argument
- {name: fromIntegral, typeApplications: 2} # >= N type arguments
- {name: id, typeApplications: forbidden} # none
```
- `required` -> "Use visible type application" when a call has none
- integer `N` -> require at least `N` (so `fromIntegral`, which needs both `a` and `b` fixed, can demand 2 -- `fromIntegral @Int` is still flagged)
- `forbidden` -> "Avoid visible type application" when a call has any
- Works on constructors in patterns too (`Just @Int x`).
## Implementation notes
- Extends the existing `RestrictFunction` value from a 2-tuple to a 3-tuple (`within`, `message`, `Maybe RestrictTypeApp`) rather than introducing a new record -- minimal diff.
- Counts type applications by summing one entry per `@T` node sharing the head name's source span; `typeAppHead` walks only the function spine.
- **Binding sites are excluded** from the check: `instance Show X where show _ = ...` defines `show` and can't carry a type application, so defining occurrences are never flagged (regression test included).
## Improvements over the original #1667
- Supports a **minimum count** (the original was presence-only, so it couldn't express `fromIntegral` needing two).
- Updated to the current ghc-lib-parser **9.12** AST (3-field `HsAppType`, 2-field `HsPar`).
- Fixes a false positive + double-report on `Show` instance definitions.
## Testing
`hlint --test` passes (970/970), including new cases in `tests/type_applications.test`: required, forbidden, count (`fromIntegral` 2), constructor patterns, and the `Show`-instance binding exclusion. Also dogfooded on a ~700-file codebase.
## Open questions for review (from a self-review pass)
1. **`Semigroup RestrictTypeApp` is partial** (`error` on `required <> forbidden`), matching the existing `RestrictIdents` style. But the old 2-tuple's `Maybe String` message just concatenated, so this introduces a *new* crash path: two same-named rules in different modules (e.g. `Data.Map.fromList` required + `Data.Set.fromList` forbidden) combined on an ambiguous use would `error`. Make it total, or keep consistent with `RestrictIdents`?
2. **`typeApplications: 0` / negatives** are silently no-ops. Reject `N < 1` in the parser?
3. The bad-string parse error (`expected 'required', 'forbidden'`) doesn't mention the integer option.