Cleanup: Moves Millard2012Equilibrium member funcs to anonymous namespace

[pepbos]

This PR moves some private member functions of Millard2012EquilibriumMuscle to free functions: i.e. a refactor/cleanup.

Currently the outputs of those functions depend partly on the input arguments, making it harder to see what the actual inputs for computing the outputs are.
The use of free functions makes this more clear.

Additionally, the use of Vector3 or Vector4 as the output of functions is reduced (by using a designated struct, or splitting into different functions).

Brief summary of changes

• Millard2012EquilibriumMuscle::calcFiberForce->Vec4 split into:
  • CalcFiberForce->double,
  • CalcActiveFiberForce->double,
  • CalcPassiveElasticFiberForce->double` and
  • CalcPassiveDampedFiberForce->double.
• Millard2012EquilibriumMuscle::calcFv moved to CalcUndampedFiberForceVelocityMultiplier
• Millard2012EquilibriumMuscle::calcDampedNormFiberVelocity moved to CalcDampedNormFiberVelocity

Testing I've completed

Unit tests are passing.
Verified output of forward integrating RajagopalModel did not change.
Performance (wall clock time) of different RajagopalModel simulations did not change.

CHANGELOG.md

• no need to update because: refactor of private member functions...

---

This change is 

[tkuchida]

You might consider naming the functions so that the common parts are at the beginning (e.g., calcFiberForceActive(), calcFiberForcePassiveElastic()). They will then appear next to each other in doxygen and autocomplete lists, and might be easier for users to find. 🐫

[nickbianco]

One minor request related to method naming.

[adamkewley]

Doesn't this new implementation re-calculate the same stuff twice? E.g. CalcFiberForce now internally does CalcActiveFiberForce and CalcPassiveFiberElasticForce. Therefore, this refactored version ends up double-computing them to save (I guess?) having to return a single Vec4.

If your intention was to simplify the implicitness of returning a packed Vec4, then I'd recommend that the refactor instead returns a struct with named members (e.g. activeFiberForce, passiveFiberElasticForce, etc.)

[pepbos]

I would expect the compiler to optimize, and remove the repeated calls, I even hinted with inline! Should i verify? Or just not do this?

[pepbos]

resolved it differently, since it was just fm = aFm + pFm,

I split it into different calls, because somewhere the total was not used, and in most places the parts were not used. So I think currently it has no repeated computations, and is not calculating more than needed.

[pepbos]

@tkuchida I was under the impression that anonynmous namespace things in cpp files will not end up in doxygen, and I don't see them there. It was also not my intention to show them in the doxygen, since they are helper functions, and not an interface to the muscle.
So, not sure I completely follow, could you clarify?

[tkuchida]

@pepbos For methods/variables that are related, it's common to name them starting with the same prefix. That way, they will appear next to each other in alphabetized lists (e.g., autocomplete) and it can be easier to find related things. It's just a convention. Presumably, someone is more likely to be interested in other things related to fiber force (calcFiberForce...()) rather than other things related to the adjectives (e.g., calcPassiveElastic...()) though not necessarily.

[pepbos]

ty @tkuchida for clarifiying, makes sense :)

[pepbos]

@tkuchida , @adamkewley , @nickbianco , ty for reviewing,I implemented your suggestions, let me know what you think

[nickbianco]

LGTM