[roll] Roll fuchsia [starnix] Fix setreuid/setregid accepting saved_uid/saved_gid for ruid/rgid

Linux's __sys_setreuid() uses asymmetric permission checks for its two
arguments: ruid can only be set to the current real UID or effective UID,
while euid can additionally be set to saved_uid. This asymmetry is
intentional — it prevents a process that dropped privileges from regaining
root via setreuid when the more explicit setresuid would be required.

Starnix used a shared new_uid_allowed() check for both arguments, which
also accepts saved_uid. This allowed setreuid(saved_uid, -1) to succeed
where Linux returns EPERM, enabling a privilege escalation path:

  setresuid(1000, 1000, 0)  // drop privileges, keep saved_uid=0
  setreuid(0, -1)           // Linux: EPERM. Starnix: success → uid=0
  setreuid(0, 0)            // full root restored

Fix: Add setreuid_ruid_allowed() and setregid_rgid_allowed() functions
that exclude saved_uid/saved_gid, matching Linux's permission model.

The existing new_uid_allowed() remains correct for setresuid (which
allows saved_uid for all three arguments) and for setreuid's euid.

Security: Local privilege escalation in Starnix credential management.
Original-Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/1575713
Original-Revision: 611de8538f6ae050d01be737e2581acc7fe14166
GitOrigin-RevId: 32172471289af444938aa62186c385431cbbd14b
Change-Id: I91954eb88bd6a777a78cfc21e095b1227bf5c42f