feat: typed StandardLineage app builder for cross-connection lineage

[mitshah-atlan]

✨ Description

Adds a typed StandardLineage builder for the Standard Lineage (cross-connection lineage) app,
which had none — callers had to hand-build the raw inputs dict for client.app.create/update.

Standard Lineage builds lineage across several connections of one connector, from query history
their own miners already extracted. One workflow owns a set of connections, so the defining
operation is re-scoping an existing workflow — adding a connection as it is onboarded. That is
what this PR makes a one-liner:

StandardLineage(client).add_connections(slug, ["default/bigquery/1700000002"])

Why hand-written rather than generated (added to the generator's _HAND_WRITTEN set) — two
things a UI configmap cannot express:

1. cross_connection_qualified_names is declared str in the app's input contract but means a
   list of connection qualified names. A native list fails validateInputsAgainstContract
   server-side; it has to be json.dumps'd, and Heracles parses it back into a list for the
   manifest placeholder. connections() takes a List[str] and encodes it.
2. Re-scoping is an update against a slug. No generated builder does updates — AppBuilder
   only has create()/run().

The re-scope path reads before it writes, and that is load-bearing rather than a convenience.
client.app.update is a full replace, and the workflow's own connection entity is republished by
the DAG's create-connection node on every run. So a rebuilt or partial connection does not merely
lose fields in the payload — the next run writes it over the real connection in Atlan, stripping its
name, admin users, admin roles, category and row limit, with no error at any point.
set_connections therefore carries the persisted connection and run_role over verbatim, read
from client.app.get(slug).dag (AppSummary tolerates unmodelled fields, so the DAG arrives as an
extra).

Surface

StandardLineage(client).connection(name=...).connections([...]).run()   # create
StandardLineage(client).add_connections(slug, [...])                    # onboard a connection
StandardLineage(client).remove_connections(slug, [...])                 # hand one back
StandardLineage(client).set_connections(slug, [...])                    # replace the scope
StandardLineage(client).get_connections(slug)                           # read the scope

add_connections / remove_connections are idempotent and return None without publishing a
version when nothing would change, so an onboarding portal can replay safely.

Validation is client-side, where the error is actionable: the app requires a non-empty,
same-connector scope, and passing the workflow's own standard-lineage connection as its scope
— a natural mistake, since both are "connections" — is rejected with a message saying which was
wanted.

Note the two distinct connectors: the workflow's own connection is minted under standard-lineage
(_CONNECTOR_NAME), while the connector input names the connector of the connections in scope and
is derived from them.

🧩 Type of change

• 🚀 New feature (non-breaking change that adds functionality)
• 🐛 Bug fix
• 🔄 Refactor
• 🧹 Maintenance
• 💥 Breaking change
• 📦 Dependency upgrade/downgrade
• 📚 Documentation updates