AArch64: add acquire load ordering to RCpc family instructions

[liamwhite]

For this function, which uses the ldapr RCpc instruction:

ldapr_test:
	ldapr	x0, [x0]
	ret

The decompiler currently doesn't note that the instruction has release-consistent processor-consistent acquire semantics with respect to the input pointer.

undefined8 ldapr_test(undefined8 *param_1)
{
  return *param_1;
}

This PR reuses the LOAcquire pcodeop to encode two arguments:

1. The address for which the RCpc acquire barrier is performed
2. The size of the load

(This could easily be changed to a distinct pcodeop if desired)

undefined8 ldapr_test(undefined8 *param_1)
{
  LOAcquire(param_1,8);
  return *param_1;
}

[GhidorahRex]

I think it's worth adding a new pcodeop LOAcquirePC but is there any specific reason that the ldapr instruction needs the address and size compared to the ldar?

[liamwhite]

For normal acquire ops, LOAcquire is a barrier that constrains all subsequent memory operations and so has no need to be parametrized. For RCpc acquires, ARM dictates that coherence guarantees are constrained to a specific address range [ptr, ptr + size) (implementing C++'s atomic::load(memory_order_acquire)).

For the purposes of emulation, it's okay to model AcquireRCpc as having the global side effect, but for source-level recreation they're not equivalent.

[GhidorahRex]

Then we definitely should include a separate pcodeop, but otherwise the PR looks good. I'll try to get all of these reviewed when I get the opportunity