Don't use projectLLVM_bv for zero-extending or truncating pointers

[RyanGlScott]

Several parts of stubs employ an anti-pattern where we use the projectLLVM_bv function immediately followed by llvmPointer_bv for the purposes of zero-extending or truncating a pointer value. Here is one part of stubs that does this:

stubs/stubs-common/src/Stubs/FunctionOverride/AArch32/Linux.hs

Lines 161 to 169 in 56851fc

	-- Zero extend return value to fit in 32-bit register and update register
	-- state.
	extendResult
	:: (1 WI.<= srcW, DMT.KnownNat srcW)
	=> LCLM.LLVMPtr sym srcW
	-> IO (LCLM.LLVMPtr sym 32)
	extendResult res = do
	asBv <- LCLM.projectLLVM_bv bak res
	AO.bvToPtr sym asBv (PN.knownNat @32)

(Note that bvToPtr is defined in terms of llvmPointer_bv.)

This is wrong when dealing with pointer arguments, as projectLLVM_bv will throw an assertion failure when the argument is a pointer. It would be more correct to project out the block number and offset (without making an assertion), adjust the offset accordingly, then reconstruct a pointer with the same block number and the adjusted offset.

It's only by sheer luck that we've managed to avoid triggering these assertion failures up until now, but I have managed to trigger this error as part of ongoing work to support PowerPC (#38). As such, I plan to fix this as part of #38.

See also #40, which is about improving the error messages in situations where we really do need to assert that a pointer is a bitvector (unlike the scenario described in this issue, where we can work with both pointers and bitvectors alike).