Adds a skeleton implementation of `StickerManagementActivityV2`. This new activity is not currently connected to anything, but once complete it will replace `StickerManagementActivity`.
The root cause:
- some MP4 files come with H.264/H.265 streams which explicitly
state their timescale. In such cases, it is wise that MP4 muxer
adopts these values
- unfortunately, the recent trend has been that such values coming
from video stream SPS (vui_parameters/timing info) are exorbitantly
high - instead of being FPS *1000, they tend to be FPS * 100,000,000
- when trying to express the duration of the movie, the MP4 muxer
normally tries to find the adequate timescale value which will
fit both audio and video timescaling domains. The most suitable
approach is that the LCM (least common multiplier) value is taken
which mathematically will be the least disruptive.
HOWEVER:
- in cases when video and timescale numeric values are mutually 'odd',
say 30*100,000,000 and 44100, the LCM ends up being a huge number,
which outgrows the 32-bit storage capacity granted by the ISO MP4
spec (MVHD box).
Problem solution:
1) identifying when the LCM timescale exceeds 32-bit storage space
2) scaling down its value by nearest larger 10X factor, which will
guarantee its value fitting the 32-bit space. Given the afore
mentioned video timescale factors, dividing by 10X is harmless
3) rescaling the duration 64-bit value based on the new timescale
Works around the glide issue by using the straight URI when possible,
which allows glide to not have to keep a buffer. However, as soon as you
select it, it'll be an encrypted file, and we'll run into this same
issue where glide needs to keep a buffer for the input stream.
Related to #11014
