Optimize BitOperations uses in CoreLib

[saucecontrol]

Following up on #35598, this updates uses of Lzcnt.LeadingZeroCount and Bmi1.TrailingZeroCount to use the equivalent BitOperations methods, which are now optimized for all xarch and for ARM64.

I also found that most uses of LeadingZeroCount were actually calculating log2. This presents opportunities to both simplify the code and to make it run faster on processors without LZCNT support as well as in R2R CoreLib.

When using LZCNT to calculate Log2, the result must be switched to the position of the highest non-zero bit. Since the LeadingZeroCount BSR and software fallbacks calculate log2 first then switch it to LZCNT, any place LZCNT is used where log2 is intended means that the fallback result is double-swapped. The changes here eliminate that.

In switching existing logic over to BitOperations.Log2, I found that most uses were protected against 0 inputs, making the zero-check branch in Log2 unnecessary. I have added an internal Log2Unsafe that skips that protection when the inputs are known to be non-zero. I also made the public Log2 branch-free, by simply setting the low bit of the input. Log2(1) is 0, and log2 of any odd number would round down anyway.

The new Log2 shows a decent performance gain over the previous improvement in #34550

BenchmarkDotNet=v0.12.1, OS=Windows 10.0.18363.778 (1909/November2018Update/19H2)
Intel Core i7-6700K CPU 4.00GHz (Skylake), 1 CPU, 8 logical and 4 physical cores
.NET Core SDK=3.1.100
  [Host]     : .NET Core 5.0.0 (CoreCLR 5.0.20.22309, CoreFX 5.0.20.22309), X64 RyuJIT
  Job-TSFLZN : .NET Core 5.0 (CoreCLR 42.42.42.42424, CoreFX 42.42.42.42424), X64 RyuJIT
  Job-BBSNWR : .NET Core 5.0 (CoreCLR 42.42.42.42424, CoreFX 42.42.42.42424), X64 RyuJIT

PowerPlanMode=00000000-0000-0000-0000-000000000000  Arguments=/p:DebugType=portable  IterationTime=250.0000 ms  
MaxIterationCount=20  MinIterationCount=15  WarmupCount=1  

Method	Job	Toolchain	Mean	Error	StdDev	Median	Min	Max	Ratio	Gen 0	Gen 1	Gen 2	Allocated
Log2_uint	Job-TSFLZN	\corerun-bitops\corerun.exe	599.7 ns	2.10 ns	1.87 ns	599.7 ns	596.6 ns	603.6 ns	0.82	-	-	-	-
Log2_uint	Job-BBSNWR	\corerun-master\corerun.exe	735.4 ns	1.58 ns	1.32 ns	735.5 ns	733.2 ns	738.2 ns	1.00	-	-	-	-
Log2_ulong	Job-TSFLZN	\corerun-bitops\corerun.exe	599.8 ns	2.28 ns	2.02 ns	599.5 ns	597.3 ns	604.6 ns	0.81	-	-	-	-
Log2_ulong	Job-BBSNWR	\corerun-master\corerun.exe	737.8 ns	3.53 ns	2.95 ns	738.3 ns	730.7 ns	742.5 ns	1.00	-	-	-	-

With LZCNT disabled, the improvement is even greater since BSR returns log2 directly. On Intel machines, the fallback is actually faster than the LZCNT version (not true for AMD unfortunately).

Method	Job	Toolchain	Mean	Error	StdDev	Median	Min	Max	Ratio	Gen 0	Gen 1	Gen 2	Allocated
Log2_uint	Job-FVXROL	\corerun-bitops\corerun.exe	555.7 ns	0.71 ns	0.59 ns	555.6 ns	554.8 ns	556.6 ns	0.62	-	-	-	-
Log2_uint	Job-JLEBRF	\corerun-master\corerun.exe	893.4 ns	2.28 ns	2.13 ns	893.3 ns	889.1 ns	897.6 ns	1.00	-	-	-	-
Log2_ulong	Job-FVXROL	\corerun-bitops\corerun.exe	555.2 ns	1.19 ns	1.05 ns	555.3 ns	552.7 ns	557.0 ns	0.62	-	-	-	-
Log2_ulong	Job-JLEBRF	\corerun-master\corerun.exe	892.6 ns	4.36 ns	4.07 ns	892.5 ns	884.8 ns	899.5 ns	1.00	-	-	-	-

[saucecontrol]

This code was dead as of #32371, since it was used only on the Vector<byte> fallback for when SSE2 is not available. Since SSE2 is required for BMI1, this was unreachable.

[saucecontrol]

BitOperations.TrailingZeroCount(ulong) is now hardware accelerated on all x64 and ARM64. On x86, the value is decomposed and accelerated as a 32-bit call, leaving ARM32 as the only candidate for this software fallback. Since it's doing 64-bit math, the decomposed LUT fallback in BitOperations is probably cheaper.

[saucecontrol]

This one is still reachable, but the fallback note from above applies.

[saucecontrol]

I tried to preserve the intent of this one, which was that hardware accelerated tzcnt should be used on little-endian. I can't think of any LE case that wouldn't be better off using BitOperations now, but I might have missed something.
cc @GrabYourPitchforks

[GrabYourPitchforks]

Thanks for the heads-up! :)
I'm not familiar enough with the larger change but this part LGTM.

[saucecontrol]

Again, this path should be faster on all supported 64-bit platforms, but I wasn't sure how that's best expressed here. Should this use conditional compilation, or an explicit if (X86Base.X64.IsSupported || ArmBase.Arm64.IsSupported)?

[jkotas]

Thanks