lint: add more details to 'statement not reached' message

In lib/libcompat/regexp/regexp.c, the FAIL macro expands to a compound
statement containing a function call statement and a return statement,
and the macro invocation is followed by a semicolon, forming an extra
empty statement. Which of these statements is unreachable now becomes
clear from the diagnostic, without having to inspect the preprocessed
source code.

branches: 1.16.2;
lint: warn about extern declarations outside headers

https://mail-index.netbsd.org/tech-userlevel/2023/03/15/msg013727.html

tests/lint: make expectation lines in the tests more detailed

This commit migrates msg_100 until msg_199.

tests/lint: make test 130 platform-independent

On 32-bit platforms such as i386 and sparc, sizeof(int) == sizeof(long),
which produced an additional unintended lint error message:

msg_130.c(78): error: duplicate case in switch: 4 [199]

branches: 1.13.2;
tests/lint: add test for enum type mismatch

lint: fix reachability for if-then-else statements

lint: disable check for enum type mismatch in switch statement

This check has been too quick and broke the lint build. Among others,
lib/libpuffs has -w included in LINTFLAGS, which means that the build
can fail even for new warnings, not only for errors.

libpuffs compares a uint16_t with constants from an unnamed enum type.
Since the enum type is completely unnamed (neither a tag nor a typedef),
there is no way to define a struct member having this type. This was a
scenario that I just didn't consider when I added the check to lint.

For now, disable the new check completely. The previously existing lint
checks stay enabled, including the one that warns about mismatched
anonymous enum types in the '==' operator, which is very similar to the
now disabled check.

tests/lint: add example for anonymous enum type in switch expression

tests/lint: add tests for comparison between unnamed enums

Since unnamed enum types cannot be used in type casts, there is no
sensible way that this type mismatch could be resolved, without changing
the definition of the enum type itself, but that may be in a
non-modifiable header.

Therefore, comparisons with enum constants of unnamed types cannot be
sensibly warned about.

lint: warn about enum/enum or enum/int type mismatch in switch

This is something that neither GCC 10 nor Clang 8 do, even though it
seems useful. Lint didn't do it up to now, but that was probably an
oversight since it is easy to miss the implicit '==' operator in the
switch statement.

tests/lint: mark tests for messages 130 and 241 as related

tests/lint: add test for incompatible enums in switch

Neither lint nor GCC 10 nor Clang 8 have a warning for an enum type
mismatch in a switch statement.

GCC 10 issues a warning but completely misses the point of the
mismatched enum types. It only warns because in this test, EVENING has
the numeric value 3, which is out of bounds for enum color, where the
valid range is from 0 to 2. It says:

> msg_130.c:45:2: warning:
> case value ‘3’ not in enumerated type ‘enum color’ [-Wswitch]

Clang 8 behaves almost the same, it just doesn't mention the value of
the constant, saying merely 'case value not in enumerated type'.

lint: add type information to enum type mismatch

tests/lint: add more tests for enum mismatch

lint: add expections to tests

msg_098: fix suffix for floating point constant
msg_127: remove prototype
msg_146: fix return type

lint: add tests for several messages

lint: add a test for each message produced by lint1

Having a test for each message ensures that upcoming refactorings don't
break the basic functionality. Adding the tests will also discover
previously unknown bugs in lint.

The tests ensure that every lint message can actually be triggered, and
they demonstrate how to do so. Having a separate file for each test
leaves enough space for documenting historical anecdotes, rationale or
edge cases, keeping them away from the source code.

The interesting details of this commit are in Makefile and
t_integration.sh. All other files are just auto-generated.

When running the tests as part of ATF, they are packed together as a
single test case. Conceptually, it would have been better to have each
test as a separate test case, but ATF quickly becomes very slow as soon
as a test program defines too many test cases, and 50 is already too
many. The time complexity is O(n^2), not O(n) as one would expect.
It's the same problem as in tests/usr.bin/make, which has over 300 test
cases as well.