… split

Problem: After bumping resourceServerVersion 1.5.2 → 1.5.3, the
:uPortal-webapp:aggregateRespondrSkins task fails with

  NoSuchMethodError: 'java.lang.CharSequence
   org.apache.commons.lang3.StringUtils.getIfEmpty(java.lang.CharSequence,
   java.util.function.Supplier)'
  at org.apache.commons.lang3.SystemProperties.getProperty(...)
  at org.apache.commons.lang3.SystemProperties.getUserName(...)

The cause is a classloader split. resource-server 1.5.3 transitively
brings commons-compress 1.28.0 onto the buildscript classpath, which
in turn pulls commons-lang3 3.18.0. commons-compress 1.28 calls into
commons-lang3 SystemProperties (introduced in 3.13), which itself
calls StringUtils.getIfEmpty(T, Supplier<T>) (added in 3.10).
Gradle 6.9.4 bundles commons-lang3 3.7 on its parent classloader and
that wins the StringUtils class resolution, so the SystemProperties
method body invokes a method that doesn't exist in 3.7. Boom.

Goal: keep aggregateRespondrSkins working without dragging Gradle's
internal lang3 forward (out of scope) and without rolling back the
resource-server release. Side note: uPortal's runtime classpath is
unaffected — this conflict is purely buildscript-scope.

Changes:
- uPortal-webapp/build.gradle: in the buildscript block, force
  commons-compress to commonsCompressVersion (1.27.1) via
  resolutionStrategy. 1.27.x doesn't touch SystemProperties, so the
  classloader split never matters.

Notes: a longer-term cleanup would be to bump Gradle (it ships much
newer commons-lang3 in 7.x+) or replace commons-compress's role here
entirely. For now this is a one-line constraint that keeps the
release moving.

…-io 2.22

Problem: After bumping resource-server to 1.5.3, this test fails
locally and in CI:

  org.apereo.portal.portlet.container.cache.LimitingTeeOutputStreamTest
    > testContentExceedsClearBuffer FAILED
    java.lang.IndexOutOfBoundsException at LimitingTeeOutputStreamTest.java:77

Line 77 was `stream.write(content, 5, content.length)`. With
content.length = 21, that's "write 21 bytes starting at offset 5",
which reads up to byte index 26 in a 21-byte array — invalid per the
OutputStream.write(byte[], int, int) contract.

The bug existed before this PR. resource-server 1.5.3 transitively
bumps commons-io 2.20.0 → 2.22.0, and 2.22's NullOutputStream is
stricter about bounds checking than 2.20's, which is what unmasked
the latent test bug.

Goal: make the test reflect what was clearly intended — write the
remaining 16 bytes after the first 5, exceeding the maxBytes=20
threshold so the limit-reached callback fires.

Changes:
- LimitingTeeOutputStreamTest.java:77: `content.length` →
  `content.length - 5` so the call is in-bounds.

Notes: also folds in the buildscript force from the previous commit
(needed for aggregateRespondrSkins). Together they unblock the
resource-server 1.5.3 bump in this PR. Verified: full
:uPortal-webapp:test now passes (297 / 0 / 78 skipped).