Fix parsing of BPM and CustomTransferMap from Elegant

[Hespe]

Description

The Elegant MONI element is currently not properly mapped to the Cheetah BPM. Furthermore, there is a slight issue with how MONI with non-zero length are handled.
Similarly the current parser for CustomTransferMap is faulty since the dtype of the resulting tensor cannot be properly inferred.

Motivation and Context

• I have raised an issue to propose this change
  • Misleading BPM import in the Elegant converter #272
  • Error in Elegant import #274

Types of changes

This PR is a breaking change, since elegant MONI elements are now mapped to BPM instead of Marker, requiring changes to downstream code.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation (update in the documentation)

Checklist

• I have updated the changelog accordingly (required).
• My change requires a change to the documentation.
• I have updated the tests accordingly (required for a bug fix or a new feature).
• I have updated the documentation accordingly.
• I have reformatted the code and checked that formatting passes (required).
• I have have fixed all issues found by flake8 (required).
• I have ensured that all pytest tests pass (required).
• I have run pytest on a machine with a CUDA GPU and made sure all tests pass (required).
• I have checked that the documentation builds (required).

Note: We are using a maximum length of 88 characters per line.

[jank324]

I feel like this should be no loop and use torch.allclose.

[Hespe]

I am not sure how torch.allclose would work here, but maybe there is some trick I am missing. The problem is that we have two elements with name d1 and therefore two separate length tensors, not one multidimensional tensor.

[jank324]

Oh I see ... I misunderstood the that line 🙃