Marking fields readonly has a couple benefits:

• Codegen can assume the value doesn't change and can inline the values into code.
• In the static constructor interpreter, we allow reading readonly fields of other classes. So class A { public static int X = 123 } class B { static int Y = A.X } - A can be preinitialized at compile time, but B cannot. However: class A { public static readonly int X = 123 } class B { static int Y = A.X } both A and B can preinitialize at compile time.

In this PR, I'm adding infrastructure to collect information about field writes during whole program analysis. This collects information about fields that are effectively read-only. Then during compilation, we use this data instead of the IsInitOnly metadata. The big advantage of this approach (as opposed to e.g. a Roslyn analyzer) is that we look at the app after trimming - some fields might be writable, but if we discarded the code that writes them, they're read only.

This is also a correctness fix - the compiler would previously assume preinitializing instances of classes with all-readonly instance fields is safe, but one can set them with reflection and this would lead to a crash in the write barrier. Not that anyone should be reflection-setting readonly fields outside of deserialization scenarios.

Cc @dotnet/ilc-contrib