Fix the interpreted version of Expression<>.Compile() for setting field on value types

[manofstick]

A bug was discovered where Expression<>.Compile(true) would return a different result to Expression<>.Compile(false). The result in the case of the interpreter meant that fields of a value type embedded within a reference type could not be set, as the interpreter was setting the fields on a boxed version of the value type.

The following unit test demonstrates this functionality:

        class Class<T>
        {
            public T Item;
        }

        struct Struct<T>
        {
            public T Item;
        }

        [Theory]
        [ClassData(typeof(CompilationTypes))]
        public static void AssignToNestedValueTypesClassStructIntTest(bool useInterpreter)
        {
            var outer =
                Expression.Parameter(typeof(Class<Struct<int>>));

            Expression<Action<Class<Struct<int>>>> e =
                Expression.Lambda<Action<Class<Struct<int>>>>(
                    Expression.Assign(
                        Expression.Field(
                            Expression.Field(
                                outer,
                                "Item"
                            ),
                            "Item"
                        ),
                        Expression.Constant(42)
                    ),
                    [outer]
                );

            Action<Class<Struct<int>>> f = e.Compile(useInterpreter);

            Class<Struct<int>> src = new Class<Struct<int>>();

            Assert.Equal(0, src.Item.Item);

            f(src);

            Assert.Equal(42, src.Item.Item); // fails for interpreted version
        }

This PR fixes this issue by utilizing TypedReference to access the fields. A special type FieldData was added into the InterpretedFrame's Data stack which is then used to determine if the slot represents a value type field access. Externally what was exposed as an object array is now wrapped, and access unwraps to the actual object upon access.

The FieldOperations class is the only class that is required to handle the added FieldData type.

NOTE: Tests for the System.Linq.Expressions library had been ignored in debug builds (due to speed reasons) but I have commented out that in order that they are executed. So presumably that change would be reversed before this PR is pulled into the mainline...