Constrain test inputs for fuzzing

Cheatcodes like cheatcode_is_rent eventually end up executing a rule like the following:

rule #addRent(Aggregate(variantIdx(0), _:List ListItem(Integer(DATA_LEN, 64, false))) #as P_ACC)
    => PAccountRent(
         #toPAcc(P_ACC),
         PRent(
           U64(?LMP_PER_BYTEYEAR),
           F64(?_EXEMPT_THRESHOLD),
           U8(?BURN_PCT)
         )
       )
  ensures 0 <=Int ?LMP_PER_BYTEYEAR andBool ?LMP_PER_BYTEYEAR <Int 1 <<Int 64
  andBool 0 <=Int ?BURN_PCT andBool ?BURN_PCT <Int 256
  andBool DATA_LEN ==Int 17 // size_of(Rent), see pinocchio::sysvars::rent::Rent::LEN

Here, the last ensures constraint, DATA_LEN ==Int 17, is on an LHS variable that comes from an unconstrained function parameter:

pub fn test_process_initialize_mint_freeze(accounts: &[AccountInfo; 2], instruction_data: &[u8; 66]) -> ProgramResult {
    cheatcode_is_rent(&accounts[1]);
    ...

Injecting constaints like this works for symbolic execution, but for fuzzing, the input is either in the right format in the first place, or we have to throw it away. The following solutions exist:

1. Annotate the source code with extra constraints, and take them into consideration when generating the inputs.
2. Modify already generated inputs
   a. using dedicated cheatcodes
   b. internally in existing cheatcodes where necessary

Start with the cheatcode_is_rent rule #addRent example and the test_process_initialize_mint_freeze entry point described in the issue. Compare the two proposed approaches for constraining generated inputs, then establish how constraints should be selected and verified before implementation; done means fuzzing no longer discards inputs that violate required formats.