Made methods non final, so we can override them

[spderman3333]

We need them overridable for the arm code.
Mainly because we need to implement a way to move to an arm position based on what position we are currently.

if (given_position in current_position.safe_positions_to_move_to) { 
  move(given_position)
} else { dont_move() }

This could theoretically be achieved with a helper method checking the safety of a given position, but I would rather the setSetpoint() do this for the assurance that someone doesn't call setSetpoint() directly, skipping the safety check.

[kcooney]

We need them overridable for the arm code. Mainly because we need to implement a way to move to an arm position based on what position we are currently.

That sounds like a good use for delegation instead of inheritance. See https://github.com/Prospect-Robotics/offseason-robot-2025/pull/37 (it's a work in progress, but the idea is we would have a class that would have a reference to Elevator and Arm, and put the logic to handle them both there).

The safe positions are a function of two motors, so I don't quite see how changing this class helps you. I'm probably missing something (we didn't have too much time to chat today).

Given how little time we have, I suggest you copy this class into offseason-robot-2025 and make your changes there. I can work independently with @anonymes-axolotole on our approach, and we can compare what we built at the end of lab on Friday

Addressed