Clean up FunctionABI and SyscallABI type signatures

[RyanGlScott]

The type signatures used in the fields of FunctionABI and SyscallABI are somewhat messy. This is a mega-issue dedicated to cleaning them up. These will likely involve some backwards-incompatible API changes.

Inconsistent use of IO versus OverrideSim in return types

The syscallArgumentRegisters and syscallNumberRegister functions return IO, but the syscallReturnRegisters function returns OverrideSim. This seems very inconsistent, given that all of these functions do very similar things. I propose that these functions either all return IO or all return OverrideSim.

Similarly, functionIntegerArguments and functionReturnAddr return IO, but functionIntegerReturnRegisters returns OverrideSim.

functionReturnAddr should return an Either, not a Maybe

(Spun off from a discussion at #38 (comment))

Currently, the return type of functionReturnAddr is IO (Maybe (MemWord (ArchAddrWidth arch))), but this arguably doesn't capture the full range of ways that this function could fail. This is best explained by looking at one implementation of functionReturnAddr:

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

Lines 200 to 225 in 56851fc

	x86_64LinuxReturnAddr bak archVals regs mem = do
	let ?ptrWidth = WI.knownNat @64
	addrPtr <- LCLM.doLoad bak mem
	(LCS.regValue stackPointer)
	(LCLM.bitvectorType 8)
	(LCLM.LLVMPointerRepr ?ptrWidth)
	LCLD.noAlignment
	res <- AVC.resolveSymBVAs bak WT.knownNat $ LCLMP.llvmPointerOffset addrPtr
	case res of
	Left AVC.UnsatInitialAssumptions -> do
	loc <- WI.getCurrentProgramLoc sym
	AP.panic AP.FunctionOverride "x86_64LinuxReturnAddr"
	["Initial assumptions are unsatisfiable at " ++ show (PP.pretty (WP.plSourceLoc loc))]
	-- This can genuinely happen if a function is invoked as a tail call, so
	-- which the main reason why this returns a Maybe instead of panicking.
	Left AVC.MultipleModels ->
	pure Nothing
	-- I'm unclear if this case can ever happen under normal circumstances, but
	-- we'll return Nothing here just to be on the safe side.
	Left AVC.SolverUnknown ->
	pure Nothing
	Right addrBV ->
	pure $ Just $ fromIntegral $ BVS.asUnsigned addrBV

Some of these cases return Nothing, while others panic. Moreover, it's conceivable that the panicking case could be reachable from user-written code.

Really, functionReturnAddr ought to return Either e (MemWord (ArchAddrWidth arch)), where e is some suitable enumeration type that covers all of the different possible failures.

syscallReturnRegisters takes a redundant CtxRepr argument

(Spun off from a discussion at #38 (comment))

Currently, syscallReturnRegisters takes both a CtxRepr atps argument as well as a RegEntry sym (StructType atps) argument. The CtxRepr atps argument is redundant, however, as it can be recovered from the RegEntry. We should remove the CtxRepr atps argument.