Efcore: Update docs for RenameTable "newSchema"

[SamHuo213]

I have some entities like so:

```C#
[Table("sensor", Schema = "asset")]
public class Sensor {
[Key]
[DatabaseGenerated(DatabaseGeneratedOption.Identity)]
[Column("id")]
public Guid Id { get; set; }
}

If I change the table name to anything (i.e. sensor to sensor_test) and run:

dotnet ef migration add <change table>

I get the following scaffold code:
```C#
            migrationBuilder.RenameTable(
                name: "sensor",
                schema: "asset",
                newName: "sensor_test",
                newSchema: "asset");

Since I didn't make changes to the schema I believe newSchema should be null per documentation (https://docs.microsoft.com/en-us/dotnet/api/microsoft.entityframeworkcore.migrations.migrationbuilder.renametable?view=efcore-2.1).

The reason why I noticed this is because I use PostgreSQL and the generated SQL code is missing a semi-colon which is probably an issues with Npgsql.EntityFrameworkCore.PostgreSQL.

The generated SQL code is:

BEGIN
    IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '') THEN
    ALTER TABLE asset."sensor" RENAME TO sensor_test;
    ALTER TABLE asset.sensor SET SCHEMA asset
    END IF;
END $$;

Further technical details

EF Core version: 2.2.0-preview2-35157
Npgsql.EntityFrameworkCore.PostgreSQL: 2.1.2
Operating system: Windows 10
IDE: Visual Studio 2017 Version 15.8.9

[roji]

See discussion in https://github.com/npgsql/Npgsql.EntityFrameworkCore.PostgreSQL/issues/700, this may need to be closed.

[roji]

The missing semi-colon is an Npgsql-only issue.

However, the fact that newSchema is included in the generated RenameTable() migration does seem like an EF Core issue as mentioned by @SamHuo213 (and @austindrenski in https://github.com/npgsql/Npgsql.EntityFrameworkCore.PostgreSQL/issues/700). It seems like there are two possibilities:

1. The documentation is right and EF Core needs to be fixed to generate null when the schema/name don't change. In this case, strictly speaking providers don't really need to compare the new value with the old in their migrations generator, since they should never be equal (although of course this behavior needs to be kept for migrations which are already generated)
2. The documentation is wrong and needs to be fixed, and providers have the responsibility of comparing the new and old values and not generating any change when they're equal.

[ajcvickers]

The current functionality is correct; the docs should be updated. @bricelam to provide more details.

[bricelam]

PR #11549 fixed an issue where we couldn't tell the difference between these two scenarios:

• The schema has not changed
• The table is being transferred to the default schema

Now, we always specify newSchema in the C#.

Providers, however, can/should be updated to not generate the ALTER TABLE..SET SCHEMA statement if the schema hasn't changed.