ENH: write and read native coordinates in VTK

[volodia99]

No description provided.

[neutrinoceros]

I rewrote the branch history to help bisect the current issue: vtk outputs are corrupted and unreadable. The breaking commit is eaa2322 (as one might expect).

I also changed back the reading logic so that

• all "surprise" fields are processed by the while loop that populates self.data
• only then, override reconstructed coordinate fields
  this is a much more flexible approach with respect to backward and forward compatibility, though I also expect we'll need to update the reading logic in the while loop so that it also accept fields of arbitrary size, which I'll try now.

[neutrinoceros]

I think a fundamental issue with our current approach is that we're writing arbitrary fields in the style of the VTK header but outside said header. We need to either:

1. change the style
2. actually add these fields to the header

I think option 2) is preferable but I don't know if it's allowed.

[neutrinoceros]

found a problem downstream: https://github.com/volodia99/nonos/pull/371#issuecomment-2459596390
Specifically, what I'm seeing is that "cell center" arrays have identical data as cell edges (the latter is correct). It may still be an issue with reading, but this needs to be clarified.

[neutrinoceros]

all clear, the issue was downstream

[glesur]

Thanks for this improvement, that seems to fix the issue of reconstructing the cell coordinates from the VTK cartesian coordinates. However, I think there is a regression: the original version of vtk_io reconstructed the cell faces and stored it in xl. Despite the "l" suffix, this was really all the cell faces, i.e. including the rightmost cell face coordinate (in other words, you have one more cell face than cell centres). With a scheme (c representing the cell centres and | the faces):

|        c         |          c         |        c         |        c           |
xl(0)   x(0)     xl(1)       x(1)      xl(2)    x(2)      xl(3)    x(3)       xl(4)

This new implementation misses that last rightmost face (xl(4) on my scheme), since you actually store dataBlock::xl which is effectively the cell left face coordinates. I think we should actually try to keep this.

[glesur]

Actually, my previous comment was incorrect, it does include the last rightmost face. So we're good to go.

[glesur]

Manually merged as github wouldn't let me do it from their website.