Runtime binder calls take a System.Type that they use for things like
accessibility checks.  The expression compiler was incorrectly passing the
result type it synthesized and the regular compiler was incorrectly
passing a nested type in the async lambda case.

Fixes #878

Fixes #2567

Fixes #2549

This reverts commit cdf6029c.

This is cleanup from DevDiv #1043494.

DevDiv 563799.

Look at a reference to Metadata spec II.23.2.16 (Short form signatures) in MetadataDecoder for explanation.

Even though there is no semantical difference between box/callvirt and constrained/callvirt here, we do not want to cause unnecessary boxing.

Compiler was handling this case correctly for structs, but missed the case of generic type parameters.
(old compiler did use constrained with generic type parameters as well)

Fixes #2111

Better handling of unary operators (like:  - foo?.Bar  )
Better lowering strategy for nullable receiver - we no longer rewrite to a ternary ?: in such cases which leads to more optimization opportunities.

The tests arep assing, but codegen is not great.

Fixes #1942.

This gives us more opportunities to fold in a case if children get lowered into ?.

Catches without awaits should not be rewritten in a context of an await catch frame since rethrow in such catch is just a regular rethrow.
Fixes #1334

Changed generation of PrivateImplementationDetails to append module name only when dealing with netmudules.

The goal of module name apending is to avoid clashes when combining multiple netmodules into multifile assembly. When building a regular assembly, appending module name is not serving any purpose and just causes unnecessary metadata differences.

Also in this change - when we do apend the module name, replace '.' with '_' when that happens. For example when we build a netmodule and its name is Foo.Bar.dll
More complicated name mangling schemes were discussed, but at this point we will do a simple '.' --> '_' as the least destabilizing change which is still sufficient in the most common case of having dots in the module name.

Fixes #1430

Fixes #760

so that there will be no conflict if they are used as netmodules
Fixes #1228

Fixes #1029

While overall parameterless constructors in structs are valid from IL perspective, without a convenient way to declare them they were virtually nonexistent. As we performed more and more testing, we kept discovering cases where parameterless struct constructors caused inconsistent behavior in libraries or even in some versions of CLR.

After reconsidering the potential issues arising from breaking long standing assumptions, we decided it was best for our users to restore the requirement on struct constructors to always have formal parameters.

Fixes #74
Closes #799