Invalid parsing when loca or glyf have null transform

[mlwilkerson]

According to the WOFF2 spec:

For 'glyf' and 'loca' tables, transformation version 3 indicates the null transform...

The relevant code in [woff2.rs](https://github.com/yeslogic/allsorts/blob/1d05ffa243d857770b45d2b0244bb2d747520bd4/src/woff2.rs#L312) is apparently trying to account for this by doing masking to get the values of bits 6 and 7...

let transformation_version = flags & 0xC0;

...and then checking for whether the value is 3 for glyf or loca:

        let transform_length = match (transformation_version, tag) {
            (3, tag::GLYF) | (3, tag::LOCA) => None,
            (_, tag::GLYF) | (_, tag::LOCA) | (1, tag::HMTX) => Some(ctxt.read::<U32Base128>()?),
            (0, _) => None,
            _ => Some(ctxt.read::<U32Base128>()?),
        };

However, if those two flag bits do actually equal 3, indicating the null transform for glyf or loca, this match statement will not get the intended result because the actual value of transformation_version will be 0xc0 (0b11000000 -- bits 6 and 7 are both true). As a consequence, that U32Base128 will be read erroneously, advancing the offset when it shouldn't, resulting in a bad file read when the reader would eventually read past the end of the file.

It seems that there either needs to be a bit shift, shifting bits 6 and 7 all the way over to test against the value of 3, or else the unshifted value should be tested against 0xc0.