Convert settings structs to consuming builders

[orium]

Two changes that should land before v3.0.0 is released:

1. b80b48e — Rename the integration_test Cargo feature to _integration_test.
2. 6922879 — Convert Settings, MemorySettings, and RewriteStrSettings to a private-fields + consuming-builder API.

Why

We bumped v2 → v3 because we needed to add fields to Settings and MemorySettings, and (since those structs had all-pub fields and were not #[non_exhaustive]) any field addition is a major-breaking change for downstream callers using struct literals. We hit this twice on the way to v3.0.0; this PR closes the door so it doesn't happen again.

1. _integration_test rename

cargo-semver-checks's default heuristic enables every Cargo feature except ones it recognises as internal (unstable, nightly, bench, no_std, or names starting with _, unstable_, unstable-). The integration_test feature didn't match, so the heuristic enabled it during semver analysis, exposed the gated pub use re-exports as part of the public API, and produced spurious breakage reports for items like TransformStreamSettings that are not actually reachable from downstream crates.

Renaming to _integration_test tells those tools the feature is internal. The feature was already documented as "Unstable: for internal use only" and is only re-exported in lib.rs behind cfg(feature = …), so this has no effect on the actual public API. The constructive byproduct is the spurious reports go away.

2. Settings → consuming builders

Settings, MemorySettings, and RewriteStrSettings now have pub(crate) fields and expose a consuming-builder API:

1. #[must_use] pub const fn with_<field>(self, value) -> Self setters for every scalar field (const where feasible).
2. #[must_use] pub fn append_<handler>(self, …) -> Self for the two Vec fields. The argument type matches what the existing element! / comments! / text! / doctype! / doc_text! / doc_comments! / end! macros already produce, so the macro outputs can be passed directly.
3. No with_* variant for Vec fields. Callers with a pre-built Vec (e.g. the C API, which receives handlers from FFI) use a loop, which is fine — Vec replacement is uncommon enough that we don't want the extra API surface.
4. #[non_exhaustive] would be redundant once fields are private, so it's not used.

Migration shape:

// Before
Settings {
    element_content_handlers: vec![element!("div", |el| { /* … */ })],
    strict: false,
    ..Settings::new()
}
// After
Settings::new()
    .with_strict(false)
    .append_element_content_handler(element!("div", |el| { /* … */ }))

All in-tree callers migrated: lib unit tests + doctests, c-api, js-api, fuzz test case, integration tests, examples, benches, and the README. The c-api uses the documented loop pattern; the js-api swaps the in-progress Settings out via std::mem::take so it can keep applying the consuming builder while sitting behind a &mut.