[SES-1652] Swap video views in calls

[ThomasSession]

Fixing: SES-1652 SES-560

Added the ability to swap videos during a call. I changed Ryan's approach to only use two renderer instead of four for optimisation.

I found several issues with the video that I hopefully addressed in this PR:

• Proper device rotation handling. The old code was relying on OrientationEventListener > onOrientationChanged, which gives us a rotation angle that doesn't take into account pitch vs roll, so tipping the device from front to back would trigger the video rotation logic, while we really only want it when the device is in portrait or landscape.
• Floating video inset state when the camera is turned off
• Fixed aspect ratio of video streams. The videos now scale appropriately based on the device's orientation, including the incoming video.
• Animated control rotation. With the new device orientation detection, I added animated control rotation when the device changes its orientation
• Fixed styling inconsistencies

Known issue:

• There is a system limitation due to the webrtc library we are using: We can't round the corners of the floating video inset when the fullscreen video stream is also enabled. That is because we can't have two surfaceViews on at the same time while still doing clipping work on them. We also can't use a TextureView as we are limited by what WebRTC supports.

[ThomasSession]

• follow the users portrait-lock

It should already follow the portrait lock from the isAutoRotateOn(). It will only check once but I don't think there is a way to know the device orientation otherwise. We could of course add the config change handling form the manifest, and request to self handle orientation changes. This would void the need for the sensor as you get that information for free, and which is what I initially started the code with. But it also means we need a separate layout for landscape instead of forcing to portrait and rotating only certain elements like we are doing now.

[bemusementpark]

It should already follow the portrait lock from the isAutoRotateOn().

yeah, but we could just add the listener, and then check this in the listener as the dead simple solution, no? possible issue if you're landscape and then you set portrait-lock. Depends how pedantic we want to get. But you could foresee that a user would have portrait lock (on/off) and start a call, and realise they want it (off/on) change the system setting and think it doesn't work, but they just have to press back and enter the call again for it to take effect... :/