M68k's SETCC instruction (`scc`) distinctly fills the destination byte
with all 1s. If boolean contents are set to `ZeroOrOneBooleanContent`,
LLVM can mistakenly think the destination holds `0x01` instead of `0xff`
and emit broken code as a result. This change corrects the boolean
content type to `ZeroOrNegativeOneBooleanContent`.

For example, this IR:

```llvm
define dso_local signext range(i8 0, 2) i8 @testBool(i32 noundef %a) local_unnamed_addr #0 {
entry:
  %cmp = icmp eq i32 %a, 4660
  %. = zext i1 %cmp to i8
  ret i8 %.
}
```

would previously build as:

```asm
testBool:                               ; @testBool
	cmpi.l	#4660, (4,%sp)
	seq	%d0
	and.l	#255, %d0
	rts
```

Notice the `zext` is erroneously not clearing the low bits, and thus the
register returns with 255 instead of 1. This patch fixes the issue:

```asm
testBool:                               ; @testBool
	cmpi.l	#4660, (4,%sp)
	seq	%d0
	and.l	#1, %d0
	rts
```

Most of the tests containing `scc` suffered from the same value error as
described above, so those tests have been updated to match the new
output (which also logically corrects them).

Had been doing this piece by piece, but makes more sense to do it in a
single PR. Adds support for `ARID`, `PCI`, `PCD`, `AL`, and `ARD`
addressing modes for atomic operations, along with a variety of tests.

The `CodeModel` tests have been rearranged, as some of the new
addressing modes are only exercised under some combinations of
`CodeModel` and relocation mode

Fixes #106208.

The m68k backend will always emit external calls (including libcalls)
with
PC-relative PLT relocations, even when in non-pic mode or -fno-plt is
used.

This is unexpected, as other function calls are emitted with absolute
addressing, and a static code modes suggests that there is no PLT. It
also
leads to a miscompilation where the call instruction emitted expects an
immediate address, while the relocation emitted for that instruction is
PC-relative.

This miscompilation can even be seen in the default C function in
godbolt:
https://godbolt.org/z/zEoazovzo

Fix the issue by classifying external function references based upon the
pic
mode. This triggers a change in the static code model, making it more in
line
with the expected behaviour and allowing use of this backend in more
bare-metal
situations where a PLT does not exist.

The change avoids the issue where we emit a PLT32 relocation for an
absolute
call, and makes libcalls and other external calls use absolute
addressing modes
when a static code model is desired.

Further work should be done in instruction lowering and validation to
ensure
that miscompilations of the same type don't occur.

Add support for the moveq instruction, which is both faster and smaller
(1/2 to 1/3 the size) than a move with immediate to register.

This change introduces the instruction, along with a set of
pseudoinstructions to handle immediate moves to a register that is
lowered post-RA.

Pseudos are used as moveq can only write to the full register, which
makes
matching i8 and i16 immediate loads difficult in tablegen. Furthermore,
selecting moveq before RA constrains that immediate to be moved into a
data
register, which may not be optimal.

The bulk of this change are fixes to existing tests, which cover the new
functionality sufficiently.

e3cf80c5c1fe55efd8216575ccadea0ab087e79c affected block placement of
some tests in the experimental m68k target. This updates them.

Put the value into A0 instead of data registers. And remove the
redundant `RetCC_M68kCommon` as there aren't many rules shared between
existing CCs other than the pointer one.
This change is tested by existing tests.

Use 'm68k' (i.e. m68k-unknown-unknown) in all codegen tests rather
than m68k-linux-gnu. NFC.

The `move` instruction has one of the most complicate sets of variants, so
we're refactoring it first before finishing up rest of the data
instructions in a separate patch.

Note that since we're introducing more `move` variants, the codegen
actually got improved in terms of code size.