perf(stream): multi-output handles answer with a plain tuple

[mario4tier]

Multi-output streaming handles now answer with the same plain tuple the Function
API returns, instead of a per-function NamedTuple. #757 issue examples have been updated
to reflect the new plain tuple API.

Why

update() on a multi-output handle spent ~125 ns/bar inside
namedtuple.__new__, against a 6 ns C call. Measured with every candidate
compiled into one binary and interleaved, so no cross-build layout scatter:

what update() returns	ns/bar	x C
NamedTuple (before)	181.6	31.6x
tuple.__new__(X_Value, ...)	131.2	21.9x
cdef class	83.1	13.9x
plain tuple (this PR)	56.5	9.4x

End to end on the real builds: MACD 169.7 -> 36.7 ns/bar, BBANDS -73.4%,
STOCH -73.9%, AROON -74.6%, MINMAXINDEX -74.9%. open_and_fill is unchanged
beyond noise, correctly: one saved construction against a 700 us call.

Two reasons beyond speed. The Function API already returns a plain tuple, so
the two tiers now agree rather than differing on the same function's outputs.

Scope

23 of 201 functions are multi-output. Single-output handles are untouched
by construction: of the 201 generated stream classes, the 178 single-output
ones are byte-identical before and after, and all 23 changed classes are
multi-output.

What to review

Five hand-written files, 34 insertions and 30 deletions:

• tools/generate_stream.py -- four edits: emit (a, b, c) at the
  update/peek/value site and at open_and_fill; stop emitting the per-function
  namedtuple; stubs emit Tuple[...] instead of a NamedTuple class
• talib/stream.py -- drop the now-dead X_Value export loop; docstring
• tests/test_stream.py, README.md, CHANGELOG

talib/_stream.pxi, talib/stream.pyi and talib/_ta_lib.c are generated.

Testing

1697 passed, on both commits independently.

test_open_and_fill_matches_batch loses its _fields check and gains a type
and arity check.