support modifying wrappers in user stages

[v4hn]

Possible features that require this interface might be

• trajectory reparameterization,
• trajectory optimization as post-processing (like MoveIt's CHOMP adapter),
• multi-trajectory blending (similar to Pilz' sequence planner)

Here is an example illustrating how difficult it is to do the same without the interface.

Fixes #208

[codecov[bot]]

Codecov Report

Merging #253 (07d8acb) into master (06b3df9) will increase coverage by 0.33%. The diff coverage is 82.54%.

:exclamation: Current head 07d8acb differs from pull request most recent head 1ef46e2. Consider uploading reports for the commit 1ef46e2 to get more accurate results

@@            Coverage Diff             @@
##           master     #253      +/-   ##
==========================================
+ Coverage   51.63%   51.95%   +0.33%     
==========================================
  Files         101      101              
  Lines        6590     6580      -10     
==========================================
+ Hits         3402     3418      +16     
+ Misses       3188     3162      -26     

Impacted Files	Coverage Δ
core/include/moveit/task_constructor/container.h	91.67% <ø> (ø)
core/include/moveit/task_constructor/container_p.h	95.66% <ø> (ø)
core/src/stages/compute_ik.cpp	79.73% <64.71%> (ø)
core/src/container.cpp	70.26% <86.49%> (-0.08%)	:arrow_down:
core/include/moveit/task_constructor/stage_p.h	96.08% <100.00%> (+3.93%)	:arrow_up:
core/src/stage.cpp	80.90% <100.00%> (+2.11%)	:arrow_up:
core/include/moveit/task_constructor/cost_terms.h	81.82% <0.00%> (-1.51%)	:arrow_down:
core/src/storage.cpp	83.79% <0.00%> (ø)
core/src/solvers/cartesian_path.cpp	85.30% <0.00%> (ø)
... and 11 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 06b3df9...1ef46e2. Read the comment docs.

[v4hn]

I just pushed a set of commits that work for me now. Please have a look @rhaschke. That took me way longer already than it should. -.-"

I didn't touch the Merger because I don't use it and we don't have any tests for it. It doesn't rely on the removed sendForward/... methods anyway because you implemented another version of them in there.

[rhaschke]

I won't have time before Thursday...

[v4hn]

Sorry, I was on sick leave last week and am working through my backlog today. I will hopefully be available for the rest of this week, so if you want we can have a call about this after I addressed everything else you pointed out here.

[v4hn]

I somewhat got stuck on a seemingly minor change I don't like to make. The current internal/external state design dictates that whereas 1 external state can map to n internal ones (to support parallel containers), each internal state can correspond to only one external state - and I thought that's fine. However, this is not actually true w.r.t. containers. Prominently ComputeIK can spawn more than one external state for the same internal (obviously once you think about it).

The options are either to modify the bimap to allow for 1:n relationships in either direction, or to split up start and end maps, because the direction of the actual 1:n relationship depends on the read/write direction. So I believe if we know whether the interface reads/writes, a single map for each interface could suffice.