Tools: Remove logic to invoke Startup.ConfigureServices

[bricelam]

The ASP.NET Core templates are changing in a way that breaks how dotnet ef and the PMC commands invoke Startup.ConfigureServices() at design-time to discover and instantiate DbContext derived types.

A new design-time entry point of Program.BuildWebHost() is being added, and we're considering adding first-class support for it in #8164.

We're taking this opportunity to try a much simpler design-time approach and clean up some of the abstractions around Startup.ConfigureServices() that leaked into our implementation.

The most noticeable change is that we're going to stop attempting to call Startup.ConfigureServices(). This means that if your DbContext derived type doesn't have a default constructor or isn't in either your startup or target project, you'll need to add an implementation of IDbContextFactory<TContext>. The tools will automatically discover this implementation on types in your startup or target project and use it. We've added a default implementation to the ASP.NET Core templates for 2.0.0-preview1 so EF Core Migrations commands will continue to work with new projects.

The rippling effects of removing the Startup.ConfigureServices() code are as follows.

• The --environment (-Environment in PMC) option on dotnet ef is being removed. Use the ASPNETCORE_ENVIRONMENT environment variable instead.
• DbContextFactoryOptions is being removed. Use AppContext.BaseDirectory instead of the ApplicationBasePath property; and Directory.GetCurrentDirectory() instead of ContentRootPath.
• We no longer discover a method named ConfigureDesignTimeServices on your Startup class. Instead, implement the IDesignTimeServices interface on a type in your startup project.