text: Title: Accumulate autogenerated migrations over multiple calls to `run_migrations()`
  Body: I am creating a multi-tenant application, with several tenant-specific schema and also public shared tables. For this I made a setup that works quite well. I'm now only struggling with the auto-generation of migrations. 
  
  I have simplified my use case to this minimal example. In `run_migrations_online`, I call several times the `context.run_migrations()`, every time with a different `target_metadata` that only concerns the table that are linked to one schema:
   
  ```python
  def run_migrations_online():
  
      connectable = create_engine(os.environ["DATABASE_URL"])
  
      with connectable.connect() as connection:
  
          schema = Schema.PUBLIC
  
          print()
          print("-" * 80)
          print(f"Migrating schema {schema.schema_name}\n")
  
          context.configure(
              connection=connection,
              target_metadata=schema.base.metadata,
              include_schemas=True,
          )
  
          with context.begin_transaction():
              context.run_migrations()
  
          schema = Schema.TENANT
  
          print()
          print("-" * 80)
          print(f"Migrating schema {schema.schema_name}\n")
  
          context.configure(
              connection=connection,
              target_metadata=schema.base.metadata,
              include_schemas=True,
          )
  
          with context.begin_transaction():
              context.run_migrations()
  
  ```
  
  When running `alembic revision --autogenerate -m "create tables"`, we can see that alembic detect correctly the modifications (one table added) for each call:
  
  ```
  --------------------------------------------------------------------------------
  Migrating schema public
  
  INFO  [alembic.runtime.migration] Context impl PostgresqlImpl.
  INFO  [alembic.runtime.migration] Will assume transactional DDL.
  INFO  [alembic.autogenerate.compare] Detected added table 'exchange_rate'
  
  --------------------------------------------------------------------------------
  Migrating schema tenant
  
  INFO  [alembic.runtime.migration] Context impl PostgresqlImpl.
  INFO  [alembic.runtime.migration] Will assume transactional DDL.
  INFO  [alembic.autogenerate.compare] Detected added table 'tenant.inventory'
  ```
  
  But the problem is that when it generate the migration script, it keeps only the modifications detected during the last call of `context.run_migrations()`, namely `tenant.inventory` table in this case:
  
  ```python
  def upgrade():
      # ### commands auto generated by Alembic - please adjust! ###
      op.create_table('inventory',
      sa.Column('id', sa.Integer(), nullable=False),
      sa.PrimaryKeyConstraint('id'),
      schema='tenant'
      )
      # ### end Alembic commands ###
  
  
  def downgrade():
      # ### commands auto generated by Alembic - please adjust! ###
      op.drop_table('inventory', schema='tenant')
      # ### end Alembic commands ###
  ```
  
  Now if I invert the order in which TENANT and PUBLIC are processed, both changes are correctly discovered, but in this case the migration script only keep tracks of `public.exchange_rate` table:
  
  ```
  --------------------------------------------------------------------------------
  Migrating schema tenant
  
  INFO  [alembic.runtime.migration] Context impl PostgresqlImpl.
  INFO  [alembic.runtime.migration] Will assume transactional DDL.
  INFO  [alembic.autogenerate.compare] Detected added table 'tenant.inventory'
  
  --------------------------------------------------------------------------------
  Migrating schema public
  
  INFO  [alembic.runtime.migration] Context impl PostgresqlImpl.
  INFO  [alembic.runtime.migration] Will assume transactional DDL.
  INFO  [alembic.autogenerate.compare] Detected added table 'exchange_rate'
  ```
  
  ```python
  def upgrade():
      # ### commands auto generated by Alembic - please adjust! ###
      op.create_table('exchange_rate',
      sa.Column('date', sa.DateTime(), nullable=False),
      sa.PrimaryKeyConstraint('date'),
      schema='public'
      )
      # ### end Alembic commands ###
  
  
  def downgrade():
      # ### commands auto generated by Alembic - please adjust! ###
      op.drop_table('exchange_rate', schema='public')
      # ### end Alembic commands ###
  ```
  
  In other words the auto-generate features generate the script only for the last run of `context.run_migrations()`.
  
  ---
  
  **Question**:
  
  Is it somehow possible to accumulate the changes over multiple calls to `context.run_migrations()` when using `autogenerate` feature?
  
  («No» is a perfectly valid answer, at least I would know I should stop trying :smile:)
  
  _Some notes_:
  
  - I have to keep this structure where I reconfigure the context several time, because when I have multiple tenants I actually want one `version_table` per tenant, and this is set using `context.configure()`.
  - Online upgrade (with `alembic upgrade head`) does not have this problem because the changes are applied directly, there is no need to accumulate them.