Allow going around PDEP catastrophe on AMD processors

[damageboy]

At the request of @danmosemsft I'm opening this issue...

There has been a recent and very unfortunate discovery about PDEP on AMD processors.
This comes from a very respected pair of performance gurus, namely the person running the famous uops.info website.

Discussion:
https://twitter.com/trav_downs/status/1203425075896225792
Repro:
https://twitter.com/uops_info/status/1202950721211162626

Screenshot (twitter being twitter and all):

To summarize: While AMD processors officially support the PDEP opcode, it is really implemented in microcode via a loop and might execute anywhere between 18-289 cycles.

This might also have potential security implications for code that performs PDEP as part of cryptographic functions that might require/rely on constant time execution (Though I'm less of an expert, maybe people like @blowdart can provide some feedback about how real this is).

In my opinion, the only proper way to handle such erratic CPU behavior (Unfortunately it's really not the last, nor the first time this sort of thing happens) is to provide HW information to developers while also making sure that the JIT can and will treat this information as a constant when it comes to code-generation.

I've already opened a separate issue for exposing these HW level constants in a more general way, but this PDEP mess also deserves some attention in its own.

[damageboy]

Looks like @InstLatx64 followed up on this with more concrete timing per mask:

https://twitter.com/InstLatX64/status/1209095219087585281?s=20

[GrabYourPitchforks]

Related: #2251

[tannergooding]

@damageboy, would you be fine with closing this given that we've updated the codebase to not use PDEP/PEXT and we are tracking exposing CPUID as its own intrinsic via #785?