New embedded boundary data structures in preparation for #5534

[RemiLehe]

When updating E (and when initializing the field values for E and B with a parser), we used to check somewhat complicated conditions that relied on the MultiFabs edge_lengths and face_areas.

This PR introduces separate arrays (m_eb_update_E and m_eb_update_B, which are iMultiFab instead of MultiFab and thus take up much less memory). These arrays contain flags that keep track of where to udpate the fields (i.e. the black crosses in the above figure). These arrays are initialized in separate functions which keep the same EB definition. (PR #5534 will then change this definition.) The code for the field pusher and field initialization uses these arrays (instead of edge_lengths and face_areas. It is thus significantly simpler and avoids duplicating complicated if conditions.

The above changes have not yet been implemented for the hybrid solver. This will instead be done in a separate PR: #5558. Once this is complete, the MultiFab edge_lengths and face_areas will not be needed anymore (except for the ECT solver), and we will thus only allocate them for the ECT solver. This should save a significant amount of memory.

[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.