Remove the exciting jump instruction from boot.S

This cjalr cra is in some code that is first hit after a cjal and so the
cjalr cra returns.  The caller then discards the value written back to
cra as the link operation in the jump-and-link instruction.  It is then
used as a call, with cra initialised to a jump address.

This was done as a code-size optimisation, but there's actually no need
to zero the registers at the start.  The code that runs with the
(possibly uninitialised) values in registers (most implementations will
zero in boot ROM or hardware anyway) all runs with access to the
primordial capabilities and so there is no way that this can possibly
leak information.

The first untrusted code runs after the *second* pass through this
block.

Simply removing this should shave 10 bytes off the loader without
affecting security.  More importantly, this is the *only* place where we
abuse cjalr in this way.  This abuse is incompatible with separating
sentries into forward and backward control-flow arcs (see
CHERIoT-Platform/cheriot-sail#54), which has a much bigger impact on security.

sdk/core/loader/boot.S

@@ -13,10 +13,10 @@
     .p2align 2
     .type start,@function
 start:
-	cjal			.Lregs_clear
-	// The common register clearing function will not zero these registers.
-	zeroRegisters	ra, sp, gp, a0
-	// At this point all registers are cleared.
+	// Most hardware will have zeroed all general-purposes registers at this
+	// point, but any code between here and the call into the scheduler has
+	// access to the root capabilities and so we are not concerned about
+	// information / capability leakage.
 #if __has_include(<platform-early_boot.inc>)
 #	include <platform-early_boot.inc>
 #endif
@@ -142,7 +142,6 @@ start:
 	addi			s1, s1, -16
 	csetbounds		ca0, csp, s1
 
-.Lregs_clear:
 	// a0 is used to pass arguments to the scheduler entry.
 	zeroAllRegistersExcept	ra, sp, gp, a0
 	cjalr			cra