Refactor `cost._evaluate` methods to accept precomputed signals about pybop

[NicolaCourtier]

I think this is a great direction to go in! 💯

Consider compute_for(y) to indicate that the computation is being applied to a given array and distinguish it from the synonym evaluate().

EDIT: After some more thought, I think using any synonym here (such as "compute" is confusing and I would instead vote for something like evaluate_on_prediction(y).

[BradyPlanden]

Thanks for the comment @NicolaCourtier!

On further thought, I think we can make better use of the __call__ method within the cost class to simplify these methods. Here's what I'm thinking:

• The __call__ method is updated to implement the current evaluate and evaluateS1 functionality, with an optional arg added as calculate_grad with default as False. This aligns with PyBaMM's solver interface, which should simplify this change for users. I think this is a nice solution as it remains non-breaking for users, with added functionality for obtaining gradients. This results in evaluate and evaluateS1 being redundant and removed. For v24.9, these should be deprecated with full removal in 24.12.
• _evaluate and _evaluateS1 are refactored into cost.compute with optional arg for returning gradients. This method computes the cost between two vectors without performing a problem.evaluate. The default would be for the ground truth and the user supplied vector, but an optional arg will be added to replace the ground truth in the computation.

To summarise, the API looks like this:

phi = cost([0.5,0.5]) # stays the same
phi, grad = cost([0.5, 0.5], calculate_grad=True) # returns cost and gradient
phi = cost.compute(np.ones(100)*4.0) # compute the cost against the ground truth and the user supplied vector
phi, grad = cost.compute(np.ones(100)*4.0, calculate_grad=True) # compute the cost and gradient against the ground truth and the user supplied vector

This is a large change to the internal cost API, as the S1 methods are removed and replaced with an optional arg in the non-gradient implementation. I think this is worth doing, as the current naming convention isn't clear to users, and would we would end up with less duplicate code. I'm be interested to hear others' thoughts on this!

[NicolaCourtier]

This sounds good to me- the function names are not direct synonyms and the amount of duplicate code will be reduced!