[roll] Roll fuchsia [arm64][iframe] Fix some assumptions about iframe layout.

Fix some assumptions about iframe layout which were made when
launching a user-mode thread.

Specifically, the layout (currently) looks like this:
```
r[30]
lr
usp
elr
spsr
```

The initial register array covers [r0, r29] and is immediately
followed by LR, which is technically the same as r30.  This said, the
structure layout _explicitly_ does not make `lr` part of the `r`
array.

Prior to this change, `arm64_uspace_entry` was assuming that `r30`
always followed `r29`.  It was treating the `r` array as if it was
declared as `uint64_t r[31]`, instead of how it was actually declared
(`uint64_t r[30]`).  This happens on the following line of the
implementation:

```
ldp x29, x30, [x0, ARM64_IFRAME_OFFSET_R + (29 * 8)]
```

If changes are made to the structure layout (to place the lr member
somewhere else, for example) this code will fail.

With all of that said, there is a LOT of low level code which makes
the assumption that certain registers are "paired" (eg; one directly
follows another in the structure layout).  This is so that
save/restore code can use the ARM load/store pair instructions to save
cycles, instead of loading registers one at a time.

To keep things clear moving forward, this CL does two things.

1) It changes `arm64_uspace_entry` to not read "past the end" of the
   C-style `r` array.  `r[30]` has 30 elements, not 31.  Don't assume
   it is either safe or correct to read past this.
2) It adds static asserts near the declaration of `iframe_t` to
   formalize the load-bearing "pairing" assumptions made by asm code.
   `r[30]` has an even number of elements, so it is implicit that
   `r[1]` always follows `r[0]`.  The new asserts also assert that
   `usp` always follows `lr`, and `spsr` always follows `elr`.

Original-Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/1446950
Original-Revision: e68921bc548e149443912b9dbda0095a4a1675f1
GitOrigin-RevId: c93b962c77259794c6ee4c650c4aeba41904cce9
Change-Id: I068c99a03bc0642f46b1c0b5ba69afae2ff1ff2f