Decide: run examples via the batteries-included Docker image instead of building from source

[scarmuega]

Decision to make

The example READMEs currently tell readers to build/run Oura from source, gating optional sinks behind Cargo features, e.g.:

cargo run --features aws --bin oura -- daemon --config daemon.toml

The published Docker image (ghcr.io/txpipe/oura:<ver>) is built --all-features, so it already includes every source/filter/sink (aws, gcp, sql, wasm, u5c, mithril, etc.) with no per-feature build step. Should the examples (and docs) recommend docker run against that image as the default, instead of a from-source cargo build?

Why it might be better

• No Rust toolchain / no per-feature flags. Today each cloud example needs the right --features flag; the image has them all.
• mithril doesn't link from source on arm64 (mithril-stm → GMP/rug); the all-features image is already the recommended way to run that example. Standardizing on the image removes that footgun.
• Lower barrier to "just try an example."

What to work out

• How the containerized Oura reaches the bundled compose services (shared docker network vs. host networking vs. host.docker.internal) and how daemon.toml's localhost URLs and relative artifact paths (./output, cursor/db files, ./snapshot) map into the container (volume mounts).
• The emulator env vars the new standalone examples rely on (AWS_ENDPOINT_URL, PUBSUB_EMULATOR_HOST) would need passing into the container.
• Possibly add each example's Oura invocation as a service in its docker-compose.yml so docker compose up runs the whole thing.
• Keep the from-source instructions for contributors/development; this is about the default "run an example" path.

Follow-up to #943 / #947.