Fix not copying constraints in setting new constraint solver

[jslee02]

Motivation

World::setConstraint() doesn't copy constraints.

Solution

Introduce ConstraintSolver::setFromOtherConstraintSolver() to properly copy skeletons and contraints from existing constraint solver. This is to let ConstraintSolver handle the copy instead of the caller (e.g., World).

---

Before creating a pull request

• Document new methods and classes
• Format new code files using clang-format

Before merging a pull request

• Set version target by selecting a milestone on the right side
• Summarize this change in CHANGELOG.md
• Add unit test(s) for this change

[mxgrey]

I have one comment about return values, but also:

Do we have any strategy for copying constraints over when cloning a world? It looks like we're not handling that currently. Since this PR is targeted at fixing a specific downstream issue for Gazebo, we can punt on the cloning concern, but it may be worth opening an issue about it if we're not currently cloning constraints.

[mxgrey]

Maybe I'm not thinking about this the right way, but shouldn't the non-const overload return a non-const reference to the vector while the const overload returns a const reference to the vector (instead of a copy of the vector)? Creating a copy should only be done if:

1. The underlying implementation does not contain a vector object that can be directly referenced
2. The API does not want to expose the implementation detail that the constraint pointers are held in a vector, in case we want to change this implementation in the future

Condition (1) doesn't apply here, and if we want to satisfy condition (2) then both the const and non-const overloads should both return a copy.

[jslee02]

Agreed. I think we should go with (2) since letting the caller to modify the list of constraints would be risky. Instead, we should enforce them to use the constraint modifier functions (add/removeConstraint).

The motivation this non-const overload returns const reference was to provide a way to iteratate the constraints or get the number of them. For this, it'd be good to provide getNumConstraint() and getConstraint(index).

[jslee02]

Do we have any strategy for copying constraints over when cloning a world? It looks like we're not handling that currently. Since this PR is targeted at fixing a specific downstream issue for Gazebo, we can punt on the cloning concern, but it may be worth opening an issue about it if we're not currently cloning constraints.

Good point! Let me fix that in a separate PR.