cc: @Anipik @safern @ericstj

While testing package validation I noticed that apparently we are filtering the assets that we consider when parsing a package here:

The problem with this, is that we will only consider those filtered files when calculating the best compile and runtime asset to verify APICompat for, but that is not always accurate, as a package could have an asset like lib/net461/_._ which should win as a runtime asset over a lib/netstandard2.0/Foo.dll when evaluating for net461, and that is not happening today. This is important as the previously mentioned example, means that effectively I would be intentionally dropping support for net461, but package validation won't catch it as it would evaluate APICompat against the netstandard2.0 asset.