android_jni: Set threads to 2 instead of CPU count

[vigneshvg]

Empirically, on Android devices with more than 1 core, it is almost always better to use 2 threads than to use number_of_cpu_cores threads.

Update the public java API function documentation to reflect this change.

The new behavior is:

• negative values map to number of cpu cores.
• zero maps to 1 or 2 depending on single core or multi core devices.
• value >=0 maps to value.

This change ensures that users who use the library via JNI take the optimal path when using the default value of 0.

[wantehchang]

In Chrome's avif_image_decoder.cc, I also set libavif's maxThreads parameter to the hardcoded value of 2. I have two reasons:

1. Almost all computers are multicore today, so I just assume a multicore computer. Not using more than two cores avoids the performance core vs. efficiency core issue we observed when working on libgav1 multithreading.
2. Chrome is likely to decode many images at the same time, so it does not make sense to use many cores for each image.

[vigneshvg]

In Chrome's avif_image_decoder.cc, I also set libavif's maxThreads parameter to the hardcoded value of 2. I have two reasons:

1. Almost all computers are multicore today, so I just assume a multicore computer. Not using more than two cores avoids the performance core vs. efficiency core issue we observed when working on libgav1 multithreading.
2. Chrome is likely to decode many images at the same time, so it does not make sense to use many cores for each image.

Yes, this change is also along the same lines. The only difference is that there are several low-end Android devices in the market which are single core. So i chose min(core_count, 2) as the default value instead of always 2.