Allow passing "protocol_options" to avio_open2

[WyattBlue]

Originally posted by @rawler in #704 (comment)

What I really need is a way to pass options to avio_open2. Note that this is already done internally by avformat_open_input, so can already be done for input-containers, but I need a way to do it for output as well.

I can see a few different ways to achieve that;

• Pass self.container_options. That somehow seems wrong. avio_open2 does not really deal with containers at all, just the underlying I/O-protocols.
• Pass self.options to avio_open2. This would create different API:s where container_options reaches avio_open2 for InputContainer, but not for OutputContainer.
• Pass self.options | self.container_options. Same problem as first, and unclear to me why we even have different option-structs if always we end up passing the union regardless?
• Pass self.protocol_options alone to avio_open2. This would work, but again create an inconsistent API between InputContainer and OutputContainer where both would support practically the same arguments, but apply them differently.

At this point, I assume the reason we're passing self.options | self.container_options for InputContainer is basic case of backwards compatibility, while enabling/encouraging applications to start passing options separately? I'm guessing we'll at some point want to break that, but make it possible for applications to be rewritten first? (Otherwise, I've misunderstood the intention with container_options.)

Given the above assumption what this PR is trying to do is; Add separate options for the 3d layer of the stack (Codecs, Containers, I/O Protocols), while not breaking backwards compatibility, and ensuring that the API remains consistent across InputContainer and OutputContainer.

• Given that avformat_open_input already have passed self.options | self.container_options to avio_open2, we must keep doing that, or risk breaking stuff.
• Given that we want to start separating protocol_options, we now allow applications to pass it in separately, and can (at some later point) deprecate it being passed to the "wrong" layer.

On the flip-side; if we don't want to enable applications to pass protocol-options separately and explicitly, why do we want it for container-options?