be810e98

Ask for a constructor and a field named after their type

A new rule, `HsPrefixNaming`: every field of a product type and every
constructor of a sum type starts with the name of the type it belongs to.

## What it asks for

```haskell
data Example = Example {exampleField :: SomeType}

data ExampleSum
  = ExampleSumOption
  | ExampleSumOther
```

Two decisions the rule makes, both argued at the fact that carries them:

- **Case is ignored when reading the prefix.** One predicate then answers for
  both roles: a field lowers the type's first letter, and a type whose name
  opens with an acronym (`URL`) has more than one letter lowered by anyone
  writing the field by hand. What a name is held to is that the *whole* of the
  type's name is there, so an abbreviation (`confPath` on `Configuration`) is
  refused.
- **An operator name is left alone in either role.** An infix constructor is
  read at its use site as the operator between its arguments rather than as a
  word, so there is nowhere in it for a prefix to go.

A field starting with its constructor's name rather than its type's passes
without a second check, because the constructor rule already makes the
constructor start with the type's name.

## Measurement against this repository

Ten fields and one hundred and twenty-four constructors across forty types.
Every one renamed rather than suppressed, which is the first two commits:

| | |
|---|---|
| fields | `entryRule` to `ruleEntryRule`, `declaredKind` to `declaredComponentKind`, `complaintList` to `complaintsList`, `settingDispatch` to `settingsDispatch` |
| constructors | `ScopeOfFile` to `ScopeKeyOfFile`, `StyleLine` to `CommentStyleLine`, `OriginDerivingStock` to `InstanceOriginDerivingStock`, `DeclValue` to `DeclKindValue`, `AttachedToDecl` to `AttachmentToDecl` |

The measurement is recorded in `plan/plan.md` beside the other M5 rules that
shipped early. `plan/rules.md` loses its `HsRecordFieldPrefix` row, which this
rule covers along with the constructor half beside it.

## Commits

Each one builds, tests and passes `nix flake check` on its own, so the renames
can be read without the rule and the rule without the renames.

1. `ba2b30b` the ten fields
2. `4c31de3` the hundred and twenty-four constructors
3. `f6d8ecb` the rule
4. `20a687b` resources for the GADT and multi-selector paths
5. `306712a` what the rule leaves alone, said and pinned
6. `77e6aa1` the language extensions nothing uses, removed
7. `24fb76e` `Trailing` renamed to `CommentPlacement`, see below
8. `6eb2944` cabal's ghc environment file kept out of the tree

## What is worth your eyes

**The constructor half is the thing to agree or disagree with.** The field half
is what `haskell-style.md` already says, and it cost ten renames. The
constructor half is new, and it gave up a convention this repository was using
deliberately: a shared prefix per type that is not the type's name, as in
`Decl*`, `Style*`, `Origin*`, `Precision*`, `Component*`. Those read as the
convention they are only to someone who already knows them, which is the
argument for the change, but some of the new names are longer than what they
replaced. `AnnotationErrorNotASuppression` and
`InstanceOriginDerivingUnspecified` are the two worth looking at hardest.

**Three renames where I chose rather than prefixed mechanically**, because the
mechanical answer stuttered:

- `AttachedToDecl` to `AttachmentToDecl`, not `AttachmentAttachedToDecl`
- `StoredModuleDidNotParse` to `StoreProblemModuleDidNotParse`, dropping the
  `Stored`
- `Unattached` to `AttachmentToNothing`, so it reads with its four siblings

**`Answered` passes without being renamed**, because `answer` is a prefix of
`answered`. That is the rule as stated doing what it says, but it is an
accident rather than a prefix anyone wrote on purpose.

## Try out

```sh
# What the rule says about its own resources.
cabal run hopinion -- module hopinion-gen/test_resources/Rule/HsPrefixNaming/bad.hs

# That the repository is clean under it.
cabal run hopinion -- check .

# The rule's text and argument, as a reader stopped by it sees them.
cabal run hopinion -- explain HsPrefixNaming
```

## Suggestions, for later rather than here

The rule reads type declarations only. A `data` instance of a data family goes
unread, since its names belong to the family rather than to the instance head
and I could not say which name a prefix should carry. If that is wrong, it is a
small change in `unprefixedNamesOf`.