putting a bunch of opened issues about IL optimisation under IL baseline tests

[smoothdeveloper]

As discussed in https://github.com/dotnet/fsharp/pull/16302#issuecomment-1819873057

This is just to have the tests under CI check in case the code gen happens to change for any reason.

Note that I've put json metadata, we can discuss in this PR if we want to do something with it yet.

[github-actions[bot]]

:heavy_exclamation_mark: Release notes required

@smoothdeveloper,

[!CAUTION] No release notes found for the changed paths (see table below).

Please make sure to add an entry with an informative description of the change as well as link to this pull request, issue and language suggestion if applicable. Release notes for this repository are based on Keep A Changelog format.

The following format is recommended for this repository:

* <Informative description>. ([PR #XXXXX](https://github.com/dotnet/fsharp/pull/XXXXX))

See examples in the files, listed in the table below or in th full documentation at https://fsharp.github.io/fsharp-compiler-docs/release-notes/About.html.

If you believe that release notes are not necessary for this PR, please add NO_RELEASE_NOTES label to the pull request.

You can open this PR in browser to add release notes: open in github.dev

Change path	Release notes path	Description
src/Compiler	docs/release-notes/.FSharp.Compiler.Service/8.0.300.md	No release notes found or release notes format is not correct

[T-Gro]

The empty .err files can be removed.

[smoothdeveloper]

There is something which currently makes IL baseline tests not robust among test runs and platform differences, related to static field.

$ use_binding_on_struct_enumerator.fsx.il.net472.release.bsl
diff at line 92:
expected:
.field static assembly valuetype '<PrivateImplementationDetails$assembly>'/T3534_24Bytes@ field3535@ at I_00003945
actual:
.field static assembly valuetype '<PrivateImplementationDetails$assembly>'/T3534_24Bytes@ field3535@ at I_00003908

I've circumvented one aspect of it, the field name, by exposing a new FSharp.Compiler.CompilerGlobalState.resetUniqueAndStamp() function, but the remaining aspect seems to be the at I_xyz aspect (I guess it is the offset in the assembly), I'm not sure what to do about it.

@KevinRansom, wondering if you have any suggestion about either mainge the assembly generation consistent so the disassembly wouldn't be affected, or another thing we could do in context of the tests, to make those IL baseline tests more robust?

I think we want IL baseline test to be suitable for more aspects than currently exercised in the test suite, to cover more ground in terms of non-regression and awareness of code generation changes.