sql: emit "drop cascades to ..." notices for all cascaded object types

**Is your feature request related to a problem? Please describe.**

PostgreSQL emits a `NOTICE: drop cascades to ` for every object removed
by a `DROP ... CASCADE`, e.g.:

postgres=# DROP TABLE t CASCADE;
NOTICE: drop cascades to view v
DROP TABLE

CockroachDB only emits this notice for a subset of cascaded object types.
Cascading to a **view**, **sequence**, or **function** produces no notice, so a
user running `DROP ... CASCADE` gets no feedback about which dependent objects
were removed:

> CREATE TABLE t(a INT PRIMARY KEY);
> CREATE VIEW v AS SELECT a FROM t;
> DROP TABLE t CASCADE; -- no "drop cascades to view v" notice

Today CockroachDB emits the notice only for:
- triggers (`drop cascades to trigger %s on table %s`)
- computed columns (`drop cascades to column %s of table %s`)

**Describe the solution you'd like**

Emit a `drop cascades to ` notice for each object removed by
a cascade, matching PostgreSQL — covering views, sequences, and functions in
addition to the trigger/column cases already handled. The declarative cascade
engine recurses through all dependent descriptors in one place
([helpers.go dropCascadeDescriptorCore](https://github.com/cockroachdb/cockroach/blob/master/pkg/sql/schemachanger/scbuild/internal/scbuildstmt/helpers.go#L224)),
which is the natural point to buffer the notices; the legacy path emits the
trigger notice from
[drop_table.go](https://github.com/cockroachdb/cockroach/blob/master/pkg/sql/drop_table.go#L762).

**Describe alternatives you've considered**

Leaving the notices as-is. This is purely an observability/PG-parity gap and has
no correctness impact — the cascade already removes the correct objects — but the
missing feedback is a UX divergence from PostgreSQL.

Jira issue: CRDB-67876

Epic CRDB-65516

Start in pkg/sql/schemachanger/scbuild/internal/scbuildstmt/helpers.go at dropCascadeDescriptorCore, then compare the legacy trigger notice in pkg/sql/drop_table.go. Trace how cascaded descriptors are identified and how notices are buffered or emitted. Done means cascaded views, sequences, and functions produce PostgreSQL-style notices alongside the existing trigger and computed-column notices.

Written by the indexing model from the issue text.