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.
Where one plan uses the other's handles, the order is the one thing to get right. A step can take a value only from a step ahead of it, so other's steps may use handles from the steps already here and not the other way round. Merged the other way round, the plan is refused when it is executed, before any of it runs.
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.