Add a new combined Corrector element

[ansantam]

Description

Implementation of a new class Corrector.
To build the Corrector class I took the old HorizontalCorrector class and added an extra entry in the transfer matrix to include yp (vertical angle). Corrector has the horizontal_angle and vertical_angle properties.

• xp is in position (1,6) of tm
• yp is in position (3,6) of tm

I then derived HorizontalCorrector and VerticalCorrector from the Corrector class.

• I originally removed either vertical_angle or horizontal_angle as property and kept the other, but this was a breaking change.
• Now angle can be used for HorizontalCorrector and VerticalCorrector, but creates additional problems (see tests)

What solution is best?

Motivation and Context

The motivation is because I need it to continue with the MAD-X converter, using the AWAKE lattice which contains combined correctors. Probably also useful to other people in the future.

• I have raised an issue to propose this change (required for new features and bug fixes)
  Closes issue New Corrector class #203

Types of changes

• 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]

So ... changing the failing test as in the following works:

def test_ea_magnets():
    """
    Test that gradients are tracking when the magnet settings in the ARES experimental
    area require grad.
    """
    ea = cheetah.Segment.from_ocelot(ares.cell, warnings=False).subcell(
        "AREASOLA1", "AREABSCR1"
    )
    incoming_beam = cheetah.ParticleBeam.from_astra(
        "tests/resources/ACHIP_EA1_2021.1351.001"
    )

    ea.AREAMQZM2.k1 = nn.Parameter(ea.AREAMQZM2.k1)
    ea.AREAMQZM1.k1 = nn.Parameter(ea.AREAMQZM1.k1)
    # ea.AREAMCVM1.angle = nn.Parameter(ea.AREAMCVM1.angle)
    ea.AREAMCVM1.horizontal_angle = nn.Parameter(ea.AREAMCVM1.horizontal_angle)
    ea.AREAMQZM3.k1 = nn.Parameter(ea.AREAMQZM3.k1)
    # ea.AREAMCHM1.angle = nn.Parameter(ea.AREAMCHM1.angle)
    ea.AREAMCHM1.horizontal_angle = nn.Parameter(ea.AREAMCHM1.horizontal_angle)

    outgoing_beam = ea.track(incoming_beam)

    assert outgoing_beam.particles.grad_fn is not None
    ```
    
 This pretty much confirms the issue. So the question is, do we solve the `Parameter` / `Buffer` assignment issue as a whole now before this can be merged, or do we merge this as a hack?
    
In terms of a hack: Just ignoring the test would in some potentially unforeseen situations break differentiability. I think a better hack would be just to make three different classes. There is even a case for that not being a hack. (Maybe a corrector transfer map function and three different classes use it (kind of like `base_rmatrix`.)

[jank324]

@ansantam, what is this? 🦦

[jank324]

Change to matrix generating function instead of inheritance as we talked about.