VideoStreamMetadata.sample_aspect_ratio: new metadata field (#733)

[carandraug]

New field to VideoStreamMetadata to at least get information about the stream sample/pixel aspect ratio. Getting this information is the minimum required to support non-square pixels.

---

This addresses issue #733 (which was deemed "reasonable" which is why I'm implementing it, thank you for considering this).

There is one thing that annoys me about this PR. The names for properties in C++ StreamMetadata and json returned by get_stream_json_metadata match. I could have separate num/den properties in StreamMetadata but I don't think that's quite right because they're actually two parts of the same value. On the json side of things I made it two separate properties because it's std::map<std::string, std::string> (although it would be trivial to make it a colon separated string and parse it on the python side of things).

[scotts]

@carandraug, thanks for tackling this! This PR actually raises an interesting design question: so far, we've only exposed metadata as strings, floats or ints. The value that's closest to the SAR that we currently have is the FPS, which we return as a float. In FFmpeg, it's an AVRational. We have not yet returned a rational as-is, without turning it into a float.

For your use-case, is it easier to have a rational, or a float? If we keep a rational, I think we should actually make it a numbers.Rational rather than just a tuple. @NicolasHug, thoughts?

[NicolasHug]

I think it would have to be a fractions.Fraction because Rational is an ABC, but agreed this is better than a plain tuple as it supports natural operations like +, float(.), etc.

Now that I think about it, we could have exposed fps as a fraction as well, but it's probably too late to do so without breaking BC?

[carandraug]

@scotts writes:

For your use-case, is it easier to have a rational, or a float? If we keep a rational, I think we should actually make it a numbers.Rational rather than just a tuple. @NicolasHug, thoughts?

From afar, I guess using a rational would be slightly simpler but I see no reason why I couldn't work a float though. However, it is trivial to get a float from a rational but not the inverse. If someone ever really needs the fraction, it will be too late to change so I'd suggest to return a rational now.

Shall I add a commit to this PR to use a fractions.Fraction instead of a tuple? Is the rest of the PR ok?