[Umbrella] Make `dynamic` understand new language features.

[VSadov]

This is an umbrella bug for all the issues related to dynamic is not being on parity with static compiler one way or another.

The reality is that while static version of the language is implemented here in https://github.com/dotnet/roslyn , the run-time behavior of the dynamic requires more.

The behavior of dynamic is implemented mostly in the dynamic binder which is a run-time component. Any work to support new language features would need to be done in that component, possibly in coordination with the static compiler - to ensure that it passes enough information to be used at run-time.

The problem here is

• versioning (what happens if old binder is used? the feature should still be blocked if possible)

• servicing of the .NET FX version of the binder. While changes to the Core FX could be done relatively easy, matching that on the .NET FX side is harder.
  .NET FX has different release cadence and different bar for fixes, and that also depends on version/milestone.

As a result - It is hard to tell at the moment when we can implement major changes/fixes to the dynamic binder.

See also https://github.com/dotnet/csharplang/issues/158

The following expression forms do not "work" with dynamic

• [ ] The null-conditional operators ?. and ?[]
• [ ] Tuple deconstruction
• [ ] Pattern-matching
• [ ] Some situations involving ref locals and returns

[tmat]

Can we move the binder to a separate package, so that each app can carry their own? We might need to rename the DLL to avoid loading the one in .NET Framework.