Give FFPoint one way to copy itself

[HugoFara]

FFPoint is the type every coordinate in the simulation passes through, and copy is defined ambiguously with assignement.

FFPoint::FFPoint(const FFPoint& p) : x(p.x), y(p.y), z(p.z) { }   // misses it
// b = a                                                                                            // copies it

FFPoint b(a); and b = a; then produce different objects.

So the assignment operator is written out, directly below the copy-constructor, where a future member has to be added to both or the omission is visible in one file. FFVector has the identical shape and gets the identical treatment. Behaviour is unchanged: the member-wise copy written here is exactly what the compiler was generating.

Verification

Unit suite 4/4, runff KML and NetCDF both match within tolerance.

One thing noticed and deliberately left alone: nothing derives from either class, so those virtual destructors cost every FFPoint a vptr for nothing. Removing them is a future decision.

Contributes to #161.

---

This pull request, including its code changes and this description, was generated by Claude Opus 5, and reviewed manually before submitting.

[antonio-leblanc]

LGTM. Went through both classes fully, not just the diff — FFPoint/FFVector only hold doubles, no owned resources, so this operator= is byte-for-byte what the compiler was already synthesizing implicitly.

Behavior's unchanged, and since nothing here touches ROS/propagation logic, no physics impact either — this is pure C++ hygiene, just silences -Wdeprecated-copy.

Safe to merge.