Android shadow performance

[albyrock87]

Description of Change

Apparently DrawShadow has an absurd impact on the performance.
Here's a speedscope from our app sorted by self time descending, also look at total time %!!!

This PR:

• moves the shadow computation to android level to avoid back and forth from C#
• uses Glide's LruBitmapPool to reduce the memory pressure on Java
• fixes shadow rendering on Android which was still broken (despite Shadows not rendering as expected on Android and iOS #24414) under some conditions (like negative offsets)

I tried as much as possible to not break signatures but given Java to C# bindings are automatically generated, there was no way completely avoid touching public APIs.

Here I've executed the testing host app with return new ShadowBenchmark(); as main page and scrolling the CV for ~30 seconds.

Before

DrawShadow takes 24%.

before.speedscope.json

After

DrawShadow is gone.

after.speedscope.json

Issues Fixed

[PureWeen]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[PureWeen]

/rebase

[PureWeen]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[AmrAlSayed0]

I'm late to the party but an attempt to improve shadow's performance was made before here #10523. Moving the code to the Java side might help but I think what would benefit the most is a shadow cache. All views that have the same size and the same shadow properties (very common scenario in CollectionView items for example) should use the same bitmap. This will eliminate a huge number of calls including C# to Java ones. There is an implementation of the shadow cache in the PR.

[albyrock87]

@AmrAlSayed0 thanks for sharing, I'll check it out.
This is still a very early WIP.
I also intend using Glide's bitmap pool for this, which should improve the performance by avoiding continuous allocations of the bitmaps.