DAL/Tezt: use attestations with DAL payload in DAL tests

Note: the author of this MR is actually @eugenz, all I did was to extract some of his work from !11760 (merged).

What

This MR makes DAL tests use regular attestations with DAL payloads instead of legacy DAL attestation operations.

Why

Dal attestation operations are about to be removed in favor of DAL payloads in regular attestations (see !11760 (merged)). We should have tests for the new way of attesting DAL slots.

How

• We extend Tezt support for attestation injection to optionally include the DAL payload.
• We patch the inject_attestation helper function in tezt/tests/dal.ml to use regular attestations.
• We patch the DAL tests where needed.

More details about the adjustement of tests:

• The block at level 1 does not accept attestations (as it's not really in Alpha), so for some tests it was necessary to bake an additional first block.

• In test_slots_attestation_operation_behavior we were testing that inserting for a past/future level doesn't work. With the new validation rules, it may work if the level is between [l-1,l+1], where l is the mempool's level. So some adjustments were needed.

• Part B of that test was removed, because it was injecting (DAL) attestations a few levels in advance. However, when injecting an attestation we need to know the hash of attested payload, which we don't know in advance. So it was not possible to adapt the test. Moreover, checking that slots are correctly attested is done in many other tests as well.

• In many cases where attestations are injected "manually", we need to take care that the attester is not one of the bakers attesting during a bake for: they will also inject attestations, and these will be in conflict with the manually injected attestation. This is why we use the pattern to this end:

  let* baker = baker_for_round_zero node ~level in
  let signer[s] = different_delegate[s] baker in
  let* _ = inject_dal_attestation[s] ~signer[s] () in
  let* () = bake_for ~delegates:(`For [baker]) client in

Manually testing the MR

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