Improve (or explain) overload resolution rules involving generic parameters.

@KathleenDollard I have come across an issue that seems like a bug to me, but may be by design, so before posting in the Rosyln repo, I wanted to discuss it here first to try and understand what is going on.

Run the following code in a console project:

```vb
Public Module Module1
Public Sub Main()
Dim NewNum = 0
Dim OldNum = 0
Dim CurNum = 0

UpdateField(NewNum, CurNum, OldNum)

Dim NewList = New List(Of String)
Dim OldList = New List(Of String)
Dim CurList = New List(Of String)

UpdateField(NewList, CurList, OldList)

Console.ReadLine()
End Sub

Private Sub UpdateField(Of T)(ByVal ArgNewValue As T,
ByRef ArgCurValue As T,
ByRef ArgOldValue As T)

Console.WriteLine("Non-list version is running.")
End Sub

Private Sub UpdateField(Of T)(ByVal ArgNewItems As IEnumerable(Of T),
ByVal ArgCurItems As List(Of T),
ByVal ArgOldItems As List(Of T))

Console.WriteLine("List version is running.")
End Sub
End Module
```

Note that the `UpdateField` sub-routine is overloaded and the compiler accepts the code so it is clearly able to distinguish between the two versions. However, when you run the code it prints `Non-list version is running.` TWICE :confounded:

Essentially the invocation `UpdateField(NewList, CurList, OldList)` which deals entirely with `List(Of T)` objects, does NOT call the second overload which has parameters of type `IEnumerable(Of T)` and `List(Of T)`.

If you further consider that `List(Of T)` implements `IEnumerable(Of T)` (a fact that is known statically at compile-time), I am having a difficult time understanding why the compiler wouldn't resolve to the second overload when calling `UpdateField(NewList, CurList, OldList)`.

Am I missing something? The [Overloaded Method Resolution](https://docs.microsoft.com/en-us/dotnet/visual-basic/reference/language-specification/overload-resolution) section of the language spec is not for the faint of heart and I am sure the explanation is in there somewhere, but overall this behaviour seems counter to the "it works the way you expect" philosophy found in other complex areas (such as VB's awesome type inference when working with lambdas).

CC: @AnthonyDGreen I see you are the sole human contributor to that part of the language spec (the other is the dotnet bot), maybe you could help shed some light here too! Specifically, would it be possible to enhance the overload resolution rules to produce the intuitive behaviour in this scenario?