fix(alter): resolve foreign keys in the table's declaration context

[dimitri-yatsenko]

With no context argument, Table.alter() resolved the definition's
foreign keys in the caller's namespace. Called from any module but the
one that declared the table, such as a migration script or a notebook
that imports the pipeline module, alter() failed for every table with a
foreign key ("Foreign key reference Item could not be resolved") unless
the caller passed context= explicitly. Part.alter() already fell back to
the declaration context; other tables did not.

alter() now uses the table's declaration context when no context is
given, and the caller's namespace only for a table that has none. An
explicit context still takes precedence. The declaration context is the
namespace the definition was written in, and alter() cannot change
foreign keys, so it resolves the references the table was declared with.

The tests write a pipeline module to a temporary directory, import it,
declare its tables in the test schema, and alter them from the test
module, on MySQL and PostgreSQL: a table that references another, which
fails without the change; its Part table through -> master; and the
same table with an explicit context that names its parent differently.
Each alter adds an attribute, since changing an attribute's type emits
MODIFY, which PostgreSQL does not accept.

Closes #1602.