addPlan
Appends every step of other, in its order, after the steps already here.
This is what makes a plan compose. One layer produces a plan for its own part of the work, another for its part, and something above them runs the two as one transaction without having to know what either put in. Handles handed out by other keep working against the merged plan and against TransactionPlanResult: a result is filed under the handle itself rather than under a position, so where a step ends up in the merged sequence changes nothing about how it is referred to.
other is not consumed and not changed - it can still be run on its own, or merged elsewhere.
Parameters
The plan whose steps to take.
Throws
INVALID_ARGUMENT where other is this plan, or holds a step this plan already holds. Running one step twice under one handle would leave the first result unreachable, the second having overwritten it.