Refactor C++ SingleStreamDecoder to consolidate addStream into constructor

Right now, the C++ SingleStreamDecoder class has two constructors: https://github.com/meta-pytorch/torchcodec/blob/1ea235aa6b71bc9d6ce070d4b849dc60974082b5/src/torchcodec/_core/SingleStreamDecoder.h#L34-L45

And separate from there, there is a public API for adding streams of different media types: https://github.com/meta-pytorch/torchcodec/blob/1ea235aa6b71bc9d6ce070d4b849dc60974082b5/src/torchcodec/_core/SingleStreamDecoder.h#L90-L97

Note that there is also a private member function that both of those call: https://github.com/meta-pytorch/torchcodec/blob/1ea235aa6b71bc9d6ce070d4b849dc60974082b5/src/torchcodec/_core/SingleStreamDecoder.h#L304-L309

This separation is a relic of when SingleStreamDecoder was trying to be more than just a single stream decoder. This API does not match the public Python API, and that fact causes some awkwardness, in particular with how we deal with custom frame mappings; see PR https://github.com/meta-pytorch/torchcodec/pull/1060#discussion_r2541371586 for more.

Note that one could imagine the current separation enables just getting metadata without adding a decoding stream, but that should be well supported with SeekMode::approximate.

Start in src/torchcodec/_core/SingleStreamDecoder.h, reviewing the constructors, public addStream API, and private helper linked in the issue. Read the custom frame-mapping discussion in PR #1060, then determine how constructor-based stream setup should align with the Python API while preserving metadata-only use through SeekMode::approximate. Done means the redundant separation is removed and both use cases remain supported.