Allow IEnumerable of tuple for DynamicData source

[Evangelink]

To avoid breaking public API, we decided to convert the tuple in object[] to preserve it. The current solution relies on ITuple which is only available in NET471+. Given we currently target net462 for full framework, that means that the feature will only be available for netcore. I'll weigh the benefit/cost ratio of adding net471 build
in the package so this feature can be available more widely.

Fixes #1335 and fixes #1624

[nohwnd]

I think it makes sense.

1. how do you guard that data that currently contain tuple are not expanded in unwanted way? Maybe there should be a flag that keeps it working as is?

2. Do you think it would make sense to add a similar "container" that is generic as the Typed Theory Data. Because ensuring that the output of the data source fits into the parameters of the test method needs to be done via an analyzer. This allows users to define their own types that have simpler constructors, but also might trap us into having to analyze all output types with inheritance. So probably no, and we just stick with tuples?

3. also please plan for analyzer that connects those pieces together. Because that is imho half of the value. I know the linked issue says that with tuples the error will be caught on compile time, but I don't see how that would be possible without an analyzer. I don't think there is any way to directly link attribute to be "spread" over method signature. But I might be wrong :))

[Evangelink]

1. how do you guard that data that currently contain tuple are not expanded in unwanted way? Maybe there should be a flag that keeps it working as is?

Not entirely sure to get the issue you are describing. Do you have some example?

2. Do you think it would make sense to add a similar "container" that is generic as the Typed Theory Data. Because ensuring that the output of the data source fits into the parameters of the test method needs to be done via an analyzer. This allows users to define their own types that have simpler constructors, but also might trap us into having to analyze all output types with inheritance. So probably no, and we just stick with tuples?

Yes, I think it makes sense as alternative, see #2227. We did something similar in TATF, it's also making it easier to provide custom name for each entry if we want.

3. also please plan for analyzer that connects those pieces together. Because that is imho half of the value. I know the linked issue says that with tuples the error will be caught on compile time, but I don't see how that would be possible without an analyzer. I don't think there is any way to directly link attribute to be "spread" over method signature. But I might be wrong :))

#2237

[nohwnd]

1. And existing method that is emulating what we do and outputs single item array with a tuple in it, and then deconstructs that in the test method. This change will break my code because my tuple will try to bind to 2 parameters instead of 1. Or no?

namespace TestProject74
{
    [TestClass]
    public class UnitTest1
    {
        [DynamicData(nameof(GetData))]
        [TestMethod]
        public void TestMethod1((string file, string mode) t)
        {
            Console.WriteLine(t.file);
        }

        public IEnumerable<object[]> GetData()
        {
            return new[]
            {
                new object[] { (file: "aaa.txt", mode: "write") }
            };
        }
    }
}

[Evangelink]

I expect that this would still work from what I have seen but I will add a test to ensure that's the case. Thanks!

[Evangelink]

I have done some manual testing and we are good. I won't add integration test here because we will need to rewrite our integration suite to allow this test and I would prefer to postpone this change for a different PR.