[Do not merge] Test checksums with new EB structures

[RemiLehe]

No description provided.

[roelof-groenewald]

Thanks for going through the effort to run this test!

It is interesting that the failing test test_3d_embedded_boundary_rotated_cube
asks for the same updated checksum values in this PR than in the one with the staircases moved:
This CI run:

New checksums file test_3d_embedded_boundary_rotated_cube.json:
{
  "lev=0": {
    "Bx": 1.252616939910365e-05,
    "By": 0.02473895628331097,
    "Bz": 0.024738956316621142,
    "Ex": 10253221.850298548,
    "Ey": 10387.334582977643,
    "Ez": 10387.532806510022
  }
}

The updated checksum values in the PR with the moved staircase:

{
  "lev=0": {
    "Bx": 1.252616939910365e-05,
    "By": 0.02473895628331097,
    "Bz": 0.024738956316621142,
    "Ex": 10253221.850298548,
    "Ey": 10387.334582977643,
    "Ez": 10387.532806510022
  }
}

[RemiLehe]

@roelof-groenewald Yes, I think I found the reason for this and fixed it in this commit:
ace399b
(which also been added to the original PR #5534)

The reason is that, with the ECT solver, MarkExtensionCells()/ ComputeFaceExtensions modify the face_areas, so MarkUpdateBCellsECT (which depends on face_areas) should be called after MarkExtensionCells()/ ComputeFaceExtensions.

[roelof-groenewald]

Cool! It is awesome that all the CI tests pass now without any checksum value changes. Seeing as you went through the work for this PR, we could merge this one as a purely code-cleaning PR, and then have #5534 be the PR that specifically changes the way the staircase-approximation is done. What do you think?
Doing it that way would provide a nice code branching point in case anybody in the future wants to test things with the old staircase setup.