PixelCopy for surface, main-thread bugfix, Optimized stack for API-31 instead of renderScript (from other pull-request by KaustubhsPatangnse)

[arberg]

From the new readme:

On API-26 and newer, Blurry uses PixelCopy to copy directly from the surface of the window,
and can thus obtain a bitmap that contains a GoogleMap. Blurry automatically use PixelCopy when using
Blurry.with(activity) instead of the deprecated Blurry.with(context).

Bugfix:
The old code of applied the Blur.of work inside main-thread, which completely negated the intention of the task. I move the blur-job out-side main.

I did some performance tests on the optimized stack (se by branch performance-test), executed on Samsung S20 FE, running API-31 = Android-12.

Performance test with 200 executions and with sampling factor 1: 
Runtime Original Stack average: 123ms
Runtime RS average: 33ms
Runtime optimized SingleThreaded average: 58ms when split into 0 jobs
Runtime optimized MultiThreaded average: 61ms when split into 8 jobs (bad image)
Runtime optimized MultiThreaded2 average: 43ms when split into 40 jobs (bad image)
Runtime optimized MultiThreaded3 average: 45ms when split into 80 jobs (bad image)

The code by KaustubhsPatangnse did not go multi-threaded. I implemented that but then the image contained errors. So the code I have pushed does not use the multi-threaded, but I left the code in, in case someone will fix it. So for the above runtimes we should ignore multithreaded. For singleThreaded its clearly faster than the original stack implementation and slower than RS on this hardware accelerated device. But the hardware acceleration is said to vanish on future devices.

[arberg]

I've updated the code today, fixing a bug where the activity surface wasn't ready yet, and also cleaning up the new code a bit.