The same issue that was reported for typecore.ml in PR#6394 did occur in
fragile pattern-matching detection code. Fix is similar: accept the fact that
in presence of recursive module some incoherence may happen.

Implements Octachron's proposal in PR#7310: warnings can now be in 4
states:

- Always: they are always active
- Implicit: they are active, but can be deactivated through external definitions
- Explicit: they are inactive, but can activated through external definitions
- Never: they are always inactive.

`warn-error` keeps its semantics: if the warning is
triggered (regardless of the activation state), a compilation error
will follow.

Warning modifiers in the warning string are now the following

- `+` put the corresponding warnings in Implicit state
- `-` in Explicit state
- `++` in Always state
- `--` in Never state
- `@` in Implicit state and triggers an error
- `@@` in Always state and triggers an error.

as of now, only warning 4 takes advantage of the four states. For any
other warning, `Always` and `Implicit` merely indicate that the
warning is active, and `Never` and `Explicit` that it is inactive.

- fixes indentation and spacing
- small code refactoring
- renaming of local variables