…e language version.

Note that we now consider a get accessor with the wrong return type to still be an override.
Issue language version suggestion when covariant returns feature would permit the override.

…ant-returns-merge-2020-04-22

Merge master to features/covariant-returns

…t/roslyn into covariant-returns-part1

…ant-returns-merge-2020-04-24

…ant-returns-merge-2020-04-24

Merge master to features/covariant-returns

…t/roslyn into covariant-returns-part1

Covariant returns part1

…able.

- Add test for override properties with setters.
- Test relaxed rules for override in source vs a metadata base type.

…ant-returns-merge-2020-04-27

Merge master to features/covariant-returns

…riding method.

Ensure that the overriden-symbol API behaves the same with or without the featue.

…ures/covariant-returns

…iant-returns

Merge master to features/covariant-returns

Covariant returns part 2

…ata.

…able entry.

…ed in C#.

…e have a place to put necessary support library declarations.

…iant-returns

Merge master to features/covariant-returns

…iant-returns

Merge master to features/covariant-returns

…iant-returns

Merge master to features/covariant-returns

…iant-returns

Merge master to features/covariant-returns

…t/roslyn into covariant-returns-e2e1

…hat is what is breaking the tests.

This updates our build to support the use of `net5.0` as a target
framework inside of our repository.

Note: this is back porting some changes from the covariant returns
branch. Wanted to get them into master sooner so we get more exposure to
them.

Check in simple end-to-end test for covariant returns on net5.0

…features/covariant-returns

…iant-returns

Merge master to features/covariant-returns

…ant returns (#46367)

* Adjust overload resolution to handle explicit overrides that skip inheritance steps in binary compat scenarios
   Fixes #45798
* Skip a flaky test.
   Relates to #46361

…features/covariant-returns