Reduce Optional allocations in SafetyEvaluator

[ash211]

Before this PR

This SafetyEvaluator class allocates Optional objects on its hot path and this allocation shows up in JFRs of the gradle daemon in a large internal project.

After this PR

==COMMIT_MSG==
Reduce Optional allocations in SafetyEvaluator
==COMMIT_MSG==

This PR reduces Optional allocation by two techniques:

1. introduce a constant OPTIONAL_OF_SAFE. Because the contained value is immutable (a conjure enum) we can create once and safely reuse where we were previously allocating a new Optional wrapper.
2. precompute an access table for the combine() method, which takes two optional safety values and returns a combined safety value. There are only (3 values + 1 empty) * (3 values + 1 empty) => 16 entries in this precomputed table, so memory usage is negligible.

Together, these save significant amounts of allocation, ~65% of 3GiB => ~2GiB by my reading of this JFR screenshots.

See 3 screenshots (large so not including inline):

1. https://github.com/user-attachments/assets/795a1c3c-226d-4c1f-ba40-06f949245e93 (36% of Optional allocations)
2. https://github.com/user-attachments/assets/e12cc152-34c8-4e0a-9c2f-f924ce9c0214 (25% of Optional allocations)
3. https://github.com/user-attachments/assets/eda37bdf-d8e9-4bbb-b60c-7542167d0de9 (4% of Optional allocations)

Possible downsides?

• There could be a bug in the logic precomputing the table, but the unit tests look very thorough and didn't catch any issues. the Preconditions.checkNotNull would fail fast if there was a missing entry of the table. The previous logic is used unchanged, just with this caching table in front.
• I considered using a Caffeine cache, but it would've required allocating Pair wrappers, and the Guava Table does not. Guava ImmutableTable will also use a dense implementation DenseImmutableTable so there is little overhead.

[changelog-app]

Generate changelog in changelog/@unreleased

What do the change types mean?

• feature: A new feature of the service.
• improvement: An incremental improvement in the functionality or operation of the service.
• fix: Remedies the incorrect behaviour of a component of the service in a backwards-compatible way.
• break: Has the potential to break consumers of this service's API, inclusive of both Palantir services
  and external consumers of the service's API (e.g. customer-written software or integrations).
• deprecation: Advertises the intention to remove service functionality without any change to the
  operation of the service itself.
• manualTask: Requires the possibility of manual intervention (running a script, eyeballing configuration,
  performing database surgery, ...) at the time of upgrade for it to succeed.
• migration: A fully automatic upgrade migration task with no engineer input required.

Note: only one type should be chosen.

How are new versions calculated?

• ❗The break and manual task changelog types will result in a major release!
• 🐛 The fix changelog type will result in a minor release in most cases, and a patch release version for patch branches. This behaviour is configurable in autorelease.
• ✨ All others will result in a minor version release.

Type

• Feature
• Improvement
• Fix
• Break
• Deprecation
• Manual task
• Migration

Description

Reduce Optional allocations in SafetyEvaluator

Check the box to generate changelog(s)

• Generate changelog entry