fix: Apply MUST_BE / IF_NOT_IN constraints to RAW INT, BOOL, STRING fields

format_param_raw() accepted MUST_BE and IF_NOT_IN visibility constraints
at the field level but format_int(), format_bool() and format_string()
never called apply_visibility_constraint(). The hide/reject rule encoded
in a signed generic-parser descriptor was therefore a no-op for any
TF_INT, TF_BOOL or TF_STRING parameter, letting attacker-controlled
calldata be approved with misleading on-device output (e.g. a signed
delta the descriptor was meant to constrain, or a boolean toggle hidden
behind an IF_NOT_IN list).

Reshape the three formatters to mirror the existing UINT/ADDRESS/BYTES
flow: they now take the `s_field` and a `to_be_displayed` flag, format
the value first, then evaluate the constraints and call
apply_visibility_constraint(). Per-type comparisons:
  * INT  — canonical decimal-string equality (matches sign-extended
    encodings of varying byte widths).
  * BOOL — both sides normalized to 0/1 before comparison.
  * STRING — byte-level length + memcmp equality.

Also reset `to_be_displayed = true` at the start of every iteration so
that an IF_NOT_IN hit on one collection element no longer drags
subsequent elements out of the review.

(cherry picked from commit e0a44d9294d0450f2eb646978a2be4de289353dc)