perf: read the catalog by join rather than by a literal id list

[JeePeeTee]

Closes #22. Benchmarked first — the numbers and the fixture are in
the issue.

The problem

A schema-only export of a 12,900-object database:

cold (plan cache cleared)   6.27 s   6.32 s   6.20 s
warm                        0.94 s   0.96 s

Six catalog queries each spliced every object id into a literal IN list — 31 KB of SQL text
for 3,000 tables. A list that size costs ~900 ms to compile; the same query then runs in 32 ms.

That is why it only bites the case it was reported from: a nightly job over seventy databases.
Object ids differ per database, so the SQL text differs, so every database compiles its own plans
and nothing is reused. Roughly seven minutes a night, all of it compilation.

The fix, and the one that does not work

The queries now join sys.objects instead of naming ids, so the text is constant.

cold   6.32 s  →  1.55 s     ~4x
warm   0.97 s  →  0.92 s     unchanged, as expected

Batching the id list — which the issue suggested, and so did I — was measured and does not
help: 917 ms against 931 ms. Each batch is a different literal list, so a different query text,
so another compilation. It trades one large compile for several smaller ones.

approach	cold	warm
literal IN list	931 ms	32 ms
batched 1,000 at a time	917 ms	47 ms
STRING_SPLIT of one parameter	109 ms	67 ms
join to sys.objects	70 ms	38 ms

I chose the join over STRING_SPLIT because the latter needs database compatibility level 130,
and this repo documents no minimum version and gates nothing on one. That floor should be a
deliberate decision, not a side effect of a performance fix.

Correctness

The queries now return rows for tables the filter excluded, so every lookup by object id checks
the map instead of trusting its zero value. Without that, a row for an excluded table would
attach its columns, indexes or constraints to tables[0].

Verified against the previous build by exporting the same database with both and comparing bytes:

(no filter)                                          identical
--include dbo.Crm*                                   identical
--include sales.* --exclude-data CrmProjectActivity  identical

A trap the test suite caught

My first version filtered the columns query on o.is_ms_shipped = 0. SQL Server reports a
user-created table type with is_ms_shipped = 1 — verified on a live instance — so every table
type lost its columns and CREATE TYPE ... AS TABLE () came out empty. Four integration tests
failed with Incorrect syntax near ')'. Table types are now matched on type alone, with a comment
recording why, since the flag looks like the obvious thing to filter on.

Checks

• full suite under -race against a live SQL Server: 8/8 packages
• round trip on a 403-table database: export 11.9 s, import 21.7 s, verify: OK
• gofmt, go vet, go build clean