Investigate the binary compatibility of readonly structs

[martintmk]

When reading this document:
https://learn.microsoft.com/en-us/dotnet/core/compatibility/library-change-rules

This section got me concerned:

If a struct has only public fields or has no fields at all, callers can declare locals of that struct type without calling the struct's constructor or first initializing the local to default(T), so long as all public fields are set on the struct before first use. Adding any new fields - public or nonpublic - to such a struct is a source breaking change for these callers, as the compiler will now require the additional fields to be initialized.

We need to investigate whether we can use read-only structs for argument classes. If adding a new member breaks binary compatibility, we should use classes instead.

As an alternative, at least on hot-paths, we can use argument pooling to reduce allocations.

[martintmk]

Based on our research we should be fine for Polly scenarios. The binary incompatibility happens when someone does not use struct constructor. In Polly we are always creating the structs ourselves and passing them to delegates.

The only scenario when the consumer needs to create a struct is for testing. But in that case, they will have to use constructor anyway to initialize it to proper test values.

Just in case I'll add the following remark to all argument structs:

/// <remarks>
/// Always use constructor when creating this struct, otherwise we do not guarantee the binary compatibility.
/// </remarks>