Allow Migrations assemble to be loaded from different assemblyLoadContexts

[davidnajar]

Currently, when developing a plugin-based mechanism where each plugin is loaded from an isolated Assembly Load Context (for instance using DotNetCorePlugins the migrations can't be loaded from a referenced asembly of the plugin. They need to stay at the same type were the plugin type is defined.
Currently there are two options for defining the assembly where migrations are located:
builder.UseSqlServer(_connectionString, b => b.MigrationsAssembly(migrationsAssembly);

being migrationsAssembly a plain string, or not specifying anything at all.

Internally, this is handled in the following way:
MigrationsAssembly.cs

 public MigrationsAssembly(
        ICurrentDbContext currentContext,
        IDbContextOptions options,
        IMigrationsIdGenerator idGenerator,
        IDiagnosticsLogger<DbLoggerCategory.Migrations> logger)
    {
        _contextType = currentContext.Context.GetType();

        var assemblyName = RelationalOptionsExtension.Extract(options).MigrationsAssembly;
        Assembly = assemblyName == null
            ? _contextType.Assembly
            : Assembly.Load(new AssemblyName(assemblyName));

        _idGenerator = idGenerator;
        _logger = logger;
    }

Note the condition: if there is not assemblyName specified it will use the same assembly where the context is defined. Otherwise will use Assembly.Load to load the assembly specified by name.

This does not work when the plugins are loaded from separate assembly load context, as the Assembly.Load is only loading assemblies from the AssemblyLoadContext.Default.

Ideally, when specifying the migrations assembly, one could give directly the Assembly object, leveraging the responsibility of how to load the assembly to the caller, and not make assumptions like the one done with the Assembly.Load. There might be an overload to the

public virtual TBuilder MigrationsAssembly(string? assemblyName)
        => WithOption(e => (TExtension)e.WithMigrationsAssembly(Check.NullButNotEmpty(assemblyName, nameof(assemblyName))));

accepting an AssemblyObject itself

[ajcvickers]

Note from triage: we discussed this and it sounds reasonable.