Add ExternalAccess package for the legacy ASP .NET Core editor

[DustinCampbell]

This change adds an "external access" project that produces a NuGet package. This project will ultimately contain a set of internal APIs that will be used to provide a stable contract that the legacy ASP .NET Core editor can communicate with, allowing other Razor APIs to evolve. For now, it's empty.

[davidwengier]

I keep going back and forth in my head about whether this should have "LegacyEditor" on the end of the project name, and I don't know the answer.

[DustinCampbell]

I keep going back and forth in my head about whether this should have "LegacyEditor" on the end of the project name, and I don't know the answer.

I think the answer is probably no. Currently, there are more things in Web Tools that use Razor that just the legacy ASP.NET Core editor, such as scaffolding. However, even if it were just the legacy editor dependency, I still probably wouldn't add that suffix anyway, since it would just serve to constrain the purpose of this project to be unnecessarily specific. E.g., what if we found another Web Tools dependency later that was less obvious, but unrelated to the legacy editor? Would we add a new "external access" project for that dependency, layering it with this external access project? Or, would we go through the effort of renaming this one? That seems like a lot of extra over-design when I think "WebTools" is probably clear enough to define its purpose for now and forever. 😄

[DustinCampbell]

I keep going back and forth in my head about whether this should have "LegacyEditor" on the end of the project name, and I don't know the answer.

@davidwengier: After our chat yesterday, I've decided to go with "LegacyEditor" rather than "WebTools". You made some excellent arguments and I agree that it's better to have a name that indicates its purpose rather than opening it up to be used for anything by a particular team. In other words, "don't ship the org chart."

Thanks very much for your thoughts!