Make BinderFlags public

[jaredpar]

The compiler currently has an IVT into the interactive layer and soon to the EditorFeatures.Wpf layer. This violates our principle of keeping the editor and compiler portions communicating via the public API surface area only. We should fix this ASAP to ensure that the internal usage doesn't spread any further.

[gafter]

@jaredpar said elsewhere:

Looking the only relevant API that is exposed is BinderFlags and only in this code (assuming a similar problem for VB)

            return new CSharpCompilationOptions(
                OutputKind.DynamicallyLinkedLibrary,
                scriptClassName: name,
                allowUnsafe: true,
                xmlReferenceResolver: null, // no support for permission set and doc includes in interactive
                usings: imports,
                sourceReferenceResolver: sourceReferenceResolver,
                metadataReferenceResolver: metadataReferenceResolver,
                assemblyIdentityComparer: DesktopAssemblyIdentityComparer.Default
                ).WithTopLevelBinderFlags(BinderFlags.IgnoreCorLibraryDuplicatedTypes);

I think we should fix this before the IVT spreads. I see two options here:

1. Make BinderFlags public
2. Make this specific option, or a subset of BinderFlags options, public

Currently leaning towards #2. This seems really like the only option we’d want to reasonably expose here.

[gafter]

I agree. I propose we add a (bool) compilation option specifically for “compilation at runtime” that would do this.

[jaredpar]

"compilation at runtime" is the scenario though, not the behavior. Shouldn't the flag express the behavior here? Was thinking something along the lines of "PreferNonCorLibraryTypes".

[tmat]

We should revisit if we still need this. I think this was a problem in early .NET Core FX. Might not be a problem anymore for 2.0+.

[jaredpar]

@tmat what would I need to validate this? Just delete it, run tests and if they pass we're good to go?