Multiple proxy listeners and upstream proxy chaining

Closes the last two items from the original "worth considering" list.

Multiple listeners: -listen takes a comma-separated address list
(-listen "127.0.0.1:8080,127.0.0.1:8081"). Server.Addr became
Server.Addrs; ListenAndServe binds every address up front - before any
of them start serving - so a bad address fails startup immediately
rather than leaving the daemon partially listening, and rolls back
already-opened listeners if a later one fails to bind. All addresses
share the same handler/history/CA/rules: one logical proxy reachable on
more than one address, not several independent proxies in one process.

Upstream proxy chaining: -upstream-proxy host:port (optional http://
prefix, stripped for convenience) routes every outbound connection
through another HTTP CONNECT proxy instead of dialing origins directly.
dialViaProxy does the CONNECT handshake to the upstream and hands back
a plain net.Conn as if it were a direct connection; dialUpstreamTLS
(CONNECT/HTTPS path) and dialUpstreamPlain (plain-HTTP path) both take
an upstreamProxy parameter and route through it when set. The two paths
need different handling: CONNECT/HTTPS is transparent below the tunnel
(once the CONNECT handshake succeeds, TLS and the request on top of it
look identical to a direct connection, so roundTripH2 and the H1 read
side need no changes at all), but plain HTTP has to send an
absolute-form request line to the upstream proxy instead of origin-form
- so roundTripH1 gained a proxyForm parameter, and forward() selects it
based on scheme=="http" && UpstreamProxy!="".

Chaining into another intercepting/MITM proxy (including another
mitmuxd) needs that proxy's own CA trusted too, or TLS verification
fails - this is inherent to chaining MITM proxies, not a gap here, and
confirmed live below rather than left as a guess.

internal/proxy/dialer_test.go: dialViaProxy against a real local CONNECT
stub (not a mock) - direct dial, successful tunnel-and-echo through a
proxy, and a proxy that refuses the CONNECT with a non-200. All three
exercise the actual network code path, not just the string-building
around it.

Verified live: started a daemon with two -listen addresses, sent
requests through both, confirmed a single shared history; killed it
mid-flight with SIGTERM and confirmed both listeners closed cleanly;
started it with one bad address in the list and confirmed startup
failed immediately with the already-bound port released, no lingering
process. For chaining: sent plain HTTP and HTTPS through a downstream
mitmuxd configured with -upstream-proxy pointing at a genuine
passthrough CONNECT stub (tunnels raw bytes, doesn't MITM) and got real
content back on both; separately chained through a second mitmuxd
instance and got the expected "certificate signed by unknown authority"
error, cleanly recorded in history rather than hanging.

go build/vet/gofmt/test/mod tidy all clean.

1 files changed, 17 insertions, 2 deletions

diff --git a/README.md b/README.md
index f65e3fe..b880fc3 100644
--- a/README.md
+++ b/README.md
@@ -123,8 +123,21 @@ go build -o bin/mitmux  ./cmd/mitmux
    ```
 
 Both binaries take flags for non-default setups - `-listen`, `-socket`,
-`-ca-dir`, `-db` on `mitmuxd`; `-socket` on `mitmux`. Run either with
-`-h` for the full list.
+`-ca-dir`, `-db`, `-upstream-proxy` on `mitmuxd`; `-socket` on `mitmux`.
+Run either with `-h` for the full list.
+
+`-listen` takes a comma-separated list to bind more than one address
+(`-listen "127.0.0.1:8080,127.0.0.1:8081"`) - one logical proxy on
+several ports/interfaces, sharing the same history, CA and rules.
+
+`-upstream-proxy host:port` chains every outbound connection through
+another HTTP CONNECT proxy (Burp, a corporate proxy, anything that
+speaks CONNECT) instead of dialing origins directly. Chaining into
+another *intercepting* proxy needs that proxy's own CA trusted too -
+it terminates and re-signs the connection with its own CA, which
+mitmux's outbound TLS client has no reason to trust otherwise; you'll
+see a clear certificate-verification error in history rather than a
+silent failure. SOCKS5 upstreams aren't implemented.
 
 ## Usage
 
@@ -330,5 +343,7 @@ reasoning behind each:
   never runs them for you (see Quick start above for why)
 - No WebSocket interception
 - No client (mutual-TLS) certificate support
+- Upstream proxy chaining (`-upstream-proxy`) is HTTP CONNECT only, no
+  SOCKS5
 - No active or passive vulnerability scanning, no plugin system - this
   is a manual-testing tool, not a scanner