Tezt_cloud: Add PPX profiling optional argument to DAL scenario

What

Add --ppx-profiling optional flag to tezt-cloud DAL scenario.

If the flag is set, then the two environment variables necessary are set as:

PROFILING=Debug PROFILING_BACKEND=txt

(one could make this configurable, but I am not sure if we really care about that, happy to do it if people want to)

Why

To be able to check profiling results in our tezt-cloud scenarios.

How

Manually testing the MR

1. TEZOS_PPX_PROFILER=profiling make - important otherwise the profiling will raise an error of the form

Fatal error: exception Failure("The profiling has been enabled with PROFILING_BACKEND='...' but the program hasn't been compiled with TEZOS_PPX_PROFILER='...'")
Raised at Stdlib.failwith in file "stdlib.ml", line 29, characters 17-33
Called from Fmt.failwith in file "src/fmt.ml" (inlined), line 25, characters 19-36
Called from Tezos_profiler_unix__Profiler_instance in file "src/lib_profiler/unix/profiler_instance.ml", lines 141-143, characters 4-66

2. Add --ppx-profiling to your DAL scenario

3. If on --localhost, you can check in your local node data directory that you have _profiling.txt files. If on proxy, you can SSH into the google cloud VM and then locate the data directory where you should find the _profiling.txt files.

Example output (mempool_profiling.txt):

...
2025-06-13T15:51:26.491-00:00
BMLyeh82RSxxhfov2hSpzPRvWMtwQoZX7HArfh9zWv12fsnu1iG ............................ 1         3705.925ms  23%
  handle_unprocessed ........................................................... 1349        57.436ms  94%
    classify pending operations ................................................ 80          36.464ms  91%
      check_signature_ed25519 .................................................. 51           6.194ms 101%
      check_signature_p256 ..................................................... 27          12.809ms  98%
      classify_operation : consensus ........................................... 170          1.342ms 100%
        freshly validated operation ............................................ 76                       
        outdated operation ..................................................... 44                       
        reclassified high priority operation ................................... 50                       
      classify_operation : manager ............................................. 2            0.011ms 108%
        freshly validated operation ............................................ 2                        
    update_advertised_mempool_fields ........................................... 80          15.863ms 100%
      advertise mempool ........................................................ 80           0.451ms  96%
      pending hashes ........................................................... 80           0.169ms 101%
      set mempool .............................................................. 80           0.557ms 103%
      union validated hashes ................................................... 80           0.270ms 100%
  leftover ..................................................................... 1                        
  on_advertise ................................................................. 15           2.648ms 101%
  on_arrived ................................................................... 78           4.951ms 100%
    already_handled ............................................................ 78           1.289ms 100%
      not already handled ...................................................... 78                       
  on_flush ..................................................................... 1            4.546ms 100%
    flush state ................................................................ 1            2.874ms 100%
      load_key(sampler_state@1570) ............................................. 1            0.293ms 100%
      load_key(stake_distribution@1570) ........................................ 1            0.059ms 102%
      load_predecessor_cache ................................................... 1            2.064ms  99%
    flushed operations ......................................................... 94           0.344ms  96%
  on_notify .................................................................... 1254       137.114ms 100%
    may_fetch_operation ........................................................ 6756       109.658ms 100%
      already fetching ......................................................... 341                      
      already_handled .......................................................... 6415        45.755ms 100%
        is_classified .......................................................... 6343                     
        not already handled .................................................... 72                       
  load_key(sampler_state@1570) ................................................. 1            0.420ms 100%
2025-06-13T15:51:30.197-00:00
BLhNBTH8Hir6Bp4zJHkUq26LDAbpeUzaf5rrJY1nETpabmok4i5 ............................ 1         3961.113ms  26%
...

Checklist

• Document the interface of any function added or modified (see the coding guidelines)
• Document any change to the user interface, including configuration parameters (see node configuration)
• Provide automatic testing (see the testing guide).
• For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR