Fix #2372: report a field's address loads on their own

[siegfriedpammer]

Fixes #2372.

FieldAccessAnalyzer.CanBeReference answered true for Ldflda/Ldsflda no matter which
analyser was asking:

case ILOpCode.Ldflda:
case ILOpCode.Ldsflda:
    return true; // always show address-loading

So an address load appeared under both "Read By" and "Assigned By", and the read-only use from
the report - flag.ToString() on a value-type field, which emits ldsflda and writes nothing -
was listed as an assignment.

What changed

The bool showWrites flag became FieldAccessKind { Read, Write, AddressOf }, each opcode group
now belongs to exactly one kind, and address loads get an analyser of their own:

[ExportAnalyzer(Header = "Address Taken By", Order = 30)]

Order 30 follows "Read By" (10) and "Assigned By" (20). Show now excludes constants for
address-of as well as for writes: a const is inlined at every use, so there is no storage to
point at.

This is the third category suggested on the issue rather than the System.Boolean::ToString
allow-list also floated there. An address load says only that something needed a reference to the
field; what happens through that reference is up to the consumer, and this analyser is an IL scan
that never looks at the consumer. Naming the methods known not to mutate their receiver would
answer this one screenshot and leave every ref argument still guessing.

Tests

FieldAccessAnalyzerTests, over a FieldAccess fixture with an instance and a static field: an
address load is not an assignment, is not a read either, is reported by the new analyser, and
plain reads and writes are unaffected. Restoring the old return true turns 4 of the 7 red,
including both halves of this issue.

ILSpy.Tests: 1280 tests, no failures.

Prepared by an AI agent (Claude, claude-opus-5, via Claude Code) and reviewed by @siegfriedpammer.

🤖 Generated with Claude Code