fix sign extension in BitField.getValue for top-bit fields

[alhudz]

BitField.getValue(int) and getValue(long) read the field with getRawValue and then shift it down with an arithmetic >>. When the field sits on the top bit of the holder (bit 31 for the int overload, bit 63 for the long overload added in 3.21.0) the masked value is negative, so >> sign-extends and the field reads back negative. new BitField(0x8000000000000000L).getValue(0x8000000000000000L) gives -1 for a one-bit field whose value is 1, and new BitField(0xFF000000).getValue(0xFF000000) gives -1 from the int overload while getValue(long) returns 255 for the same field.

Use the unsigned >>> in both getters so the selected bits come down as magnitude. The value is reconstructed at the shift, so fixing it there also covers getShortValue/getByteValue, which delegate through getValue, and it leaves the mask handling from #1711 untouched. Fields that do not reach the top bit are unchanged because >> and >>> agree on a non-negative value.