Allow for backwards compatibility in filters when `free_energy` is not present

Checklist

• I have read the contribution guidelines.
• Unit tests have been added for any new or changed code, and the test suite passes. Note: Your request will likely not be merged without the appropriate tests.
• "closes #XXXX" is in the body of the MR description to link the related issue, if applicable.

This closes #1376 (closed) to address the general problem where third-party calculators often do not have free_energy implemented as a property, either because it does not make physical sense for that type of simulation or because it was not deemed viable or important. The concept of a "force-consistent energy" is only applicable to a subtype of simulations supported by ASE, and enforcing its presence on all calculators is problematic. There are additional complications associated with the chosen name; for instance, the concept of a "free_energy" is not the same as a force consistent energy in molecular DFT codes.

For these reasons, we should not rely on the fact that all calculators have a free_energy property. However, the filters class requires it. This MR falls back to regular energy if free_energy is not present.

Related: https://github.com/tblite/tblite/issues/137. There are a whole suite of third-party calculators that break due to the current behavior.