More AD review updates

[JeromeMartinez]

This is part of the fixes requested in an IETF AD review.
A detailed answer, line per line of the review, is coming.

[dericed]

LGTM :)

[michaelni]

"More AD review updates"

Please split this in one commit per fix with a terse but larger than 0 bytes explanation for each

[michaelni]

Removing english definitions of intermediates does not seem a good idea to me
random example: "the slice vertical position in pixels."
this can surely all be defined by code expressions but that could make it harder to understand

[JeromeMartinez]

Removing english definitions of intermediates does not seem a good idea to me

I misunderstood the AD request. I put chapters and definitions back. I kept the change of how to indicate the definition of plane_pixel_height and plane_pixel_width (separated feedback about the weirdness of the definition, and now it is more coherent with how it is done for other definitions).

Please split this in one commit per fix

Done. please review again.

[dericed]

I re-reviewed after the pr was rebased and this looks good to me. There are some remaining issues from Murray's review that I can fix, so I send a pull request after this one is merged.

[dericed]

nudging here to be responsive to the ietf review.

[michaelni]

Ive merged a bunch of these. Some hesitation i had with
"... a content with ..." that sounds a bit odd has someone who knows english well approved this ?

"SHOULD reject a content with version == 2"

Why should a version 3 or 4 specification contain such a recommandition ?

-If colorspace_type is 1, then chroma_planes MUST be 1, log2_h_chroma_subsample MUST be 0, and log2_v_chroma_subsample MUST be 0.
+Decoders SHOULD reject a content with colorspace_type == 1 && (chroma_planes != 1 || log2_h_chroma_subsample != 0 || log2_v_chroma_subsample != 0).

First and foremost we need to describe what is the correct bitstream and what is the correct output for an encoder to generate. Otherwise we will end up with incorrect bitstreams.
Other specifications generally do not describe what a decoder should do with things that are not valid. I see no reason why we should stray from this path ISO/ITU are using.

Move note for future implementation to an appendix

I dunno, that does more than move

i also see "Warning: Too long line found (L770), 5 characters longer than 72 characters:" not sure where this was introduced

[JeromeMartinez]

I close this PR it as it is superseded by #202.