fix: add CorvusOS's build fingerprint for LG V50 (flashlmdd)

[ohaiibuzzle]

This PR adds an OR condition for the check on flashlmdd's build fingerprint to support CorvusOS's last official release build fingerprint (lge/corvus_flashlmdd/flashlmdd:13/TD1A.221105.001/1668359496:user/release-keys) in addition to the one from the stock firmware from LGE.

Now, the (obvious) question:

Why would anyone do this?

See, the issue with using LG's stock vendor is that some functionality breaks under most if not all GSIs:

• The Assistant key is, for some reason, mapped to INFO, not ASSIST using LG's stock vendor, causing it to not work on basically anything
• Vibration, which is managed by the LG daemon immvibed, straight up does not work. That daemon appears to check for device build fingerprint, OEM and even the Android version before it would do anything with the vibration motor.
• Not all cameras work (this device have 5: 2 front, 3 back). For some reason the back telephoto and front UW doesn't show up
• The back side notification light (the 5G logo) doesn't actually work as a notification light (it just cycles uncontrolled)

By using Corvus as a base, GSIs benefits from:

• A newer Vendor implementation (VNDK 33, Android 13 based)
• Mentioned features works as expected
• Actually have a unique enough build strings. Another ROM (ricedroid 8.0) that is commonly used as a GSI base uses cheetah in its fingerprint google/cheetah/cheetah:13/TD1A.221105.003/9229241:user/release-keys, no good for identifying what the device.

I'm fairly sure this may break a rule somewhere with overlays, but gonna attempt to PR this anyway, since it does improves the general experience for GSIs on these devices

[phhusson]

All those issues ought to be fixed GSI-side... Anyway, I can accept that change but use * instead of explicitly mentioning corvus. Something like +lg/*flashlmdd*

[ohaiibuzzle]

All those issues ought to be fixed GSI-side...

I agree with you on that one, they definitely should be fixed there. The issue however is that to fix these specific combination of issues on stock vendor would require GSI builders to fix each of them specifically for this device alone (or at least for LGE's devices, I think the G8 also run into these issues on stock vendor). Kinda on the harder side, given that this thing itself is not very popular

I think just having people install an alternative vendor implementation that already have them patched out before installing GSIs would just be simpler in this case