Add orthogonal setup-local flags: --no-constraints and --no-dbconnect

[rugpanov]

Why

databricks environments setup-local had a single --constraints-only mode that
bundled "skip databricks-connect" together with the rest of the setup. Callers
need to control the setup axes independently — skip the remote pins, or skip the
databricks-connect dependency — so the flags that control them should be
orthogonal.

What

Two orthogonal, composable negative flags:

• --no-constraints — skip writing the remote Python-version and dependency
  pins (requires-python and the [tool.uv] constraint block). Existing values
  are left untouched, and (when provisioning) the resolved Python is still
  installed — the flag only governs what is written.
• --no-dbconnect — skip the databricks-connect dependency. Equivalent to
  the existing --constraints-only, which is left in place for now (either flag
  triggers the same behaviour).

The --no-constraints "unmanaged" signal is a nil ConstraintDeps / empty
requires-python. parseConstraints normalizes a missing
[tool.uv].constraint-dependencies to a non-nil empty slice, so nil uniquely
means the flag rather than an artifact that simply omits the section.

Note on --no-constraints + provisioning

--no-constraints governs only what is written. A provisioning run still installs
and validates the resolved Python, so if a user's kept requires-python is
disjoint from the target, uv surfaces it as a normal E_PROVISION rather than the
command guessing an alternative.

Backward compatibility

Default runs (no new flags) produce byte-for-byte identical output and behaviour
— every existing acceptance golden is unchanged except the refreshed --help
listing.

Testing

• Unit (libs/localenv): --no-constraints leaves existing pins untouched
  and omits them greenfield; parseConstraints normalizes a missing
  constraint-dependencies.
• Acceptance (acceptance/localenv): no-constraints and no-dbconnect
  goldens, plus the refreshed help output.
• gofmt, go vet, and full go build ./... clean; rebased on latest main.

This pull request and its description were written by Isaac.

[rclarey]

Mostly LGTM, but some of the flag combinations have non-obvious consequences to me

• --constraints-only + --no-constraints is nonsense, but I guess we don't want to remove --constraints-only for backwards compatibility?
• is --no-constraints + --no-dbconnect + --no-provision meaningful? It seems this does some checks / fetches the constraints artifact but does nothing with it? Is there a case where someone would want all 3 together?

[rclarey]

Why not thread the --no-constraints flag through so we don't need a special signal value? (same is true for other signal values used elsewhere)