REPLAY-1892 Sanitize invalid CGColor values

[ncreated]

What and why?

📦 This PR adds a guard logic in SR to prevent it from crashing the app if the assumed value of view.layer.borderColor is not a valid CGColor object.

Such situation is likely possible in apps that leverage User Defined Runtime Attributes and do it wrong like in this example:

Although the layer.borderColor seems to be set properly, at runtime it is resolved to UIDynamicCatalogSystemColor at runtime, which isn't compatible with CGColor. Calling layer.borderColor?.alpha in such case will crash the app. Interestingly, this seems to only impact view.layer properties as they use CG* types. Setting view.backgroundColor this way will work because UIKit is smart enough to resolve UIColor properly.

We consider this likely and possible, hence we want to prevent SR from causing crashes by adding safety check.

How?

Added basic check with CFGetTypeID(_:) to guard if the typeID of received CGColor is indeed CGColor.typeID.

The fact that view attribtues are captured in with immutable ViewAttributes construct helped to centralise this check. Added second sanity check in the hexString(from:) logic, which is the only place where we query assumed CGColor objects.

Review checklist

• Feature or bugfix MUST have appropriate tests (unit, integration)
• Make sure each commit and the PR mention the Issue number or JIRA reference
• Add CHANGELOG entry for user facing changes

Custom CI job configuration (optional)

• Run unit tests
• Run integration tests
• Run smoke tests