Inliner: initial data gathering for code size estimates

Inliner: initial data gathering for code size estimates

Some initial work to gather data to drive the modelling of inline
code size impact. See #3775 for context.

Update the `DiscretionaryPolicy` to capture more observations.

Add a limit feature `JitInlineLimit` so the jit will stop inlining after
a given number of successful inlines.

Add a `DumpData` method to `InlinePolicy` which will display all the
observations that were made to evaluate an inline. Implement this for the
`DiscretionaryPolicy`. Add a matching `DumpSchema` that writes out
column headers for each of the observations.

Modify `InlineResult` to cache the last successful policy on the root
compiler instance. Use that along with the `JitInlineLimit` and
`DumpData` to display detailed information about the last sucessful
inline along with the code size for the method. All this is displayed
if `JitInlineDumpData ` is enabled.

This allows for isolating code size measurements as follows. Compile or
jit something with `JitInlineLimit = 0` and `JitInlineDumpData =1` (and
for now, `JitInlinePolicyDiscretionary = 1`, since other policies do not
implement any interesting data dumping).

Record the this root set of method sizes and IDs. Repeat with
`JitInlineLimit=1`. For each method where there was an inline, the size
impact of that inline can be computed by comparing this version versus
the version from the root set. Repeat with `JitInlineLimit=2`, comparing
versus the `=1` versions.

Currently the method token is used to identify the root method. This is
not sufficiently unique but unfortunately there currently aren't
substantially better alternatives. See #1957 for some discussion.