MainPodBuilder does not reuse Contains statements from input PODs

[robknight]

When encountering the use of an anchored key argument, MainPodBuilder will insert a Contains statement for the key that is being used, unless one has already been added to the current POD. However, this fails to account for the case where that Contains statement is already present as a public statement of an input POD, and therefore does not need to be created again.

Because there is no guarantee that the input POD will be added before the operation which uses the anchored key, it may make sense to switch to a de-duplication approach rather than attempting to track which Contains statements exist during operation insertion.

[ed255]

I think that the deduplication approach can have some complexity:

Do we dedup at the end? Currently the MainPodBuilder checks the limits of the pod for every new statement added. If we do dedup at the end we should change that and only check the limits at the end. This removes the opportunity to find the error earlier.

Do we do dedup for every statement insertion? Then we may need to remove statements if a input pod is added which already contains a statement the user added manually.

Given the new MultiPodBuilder perhaps there's no need for the MainPodBuilder to track the limits at each step? See #463

As a temporary simple solution until we figure out the proper role of the MainPodBuilder code we could do the following:

• Only if the input pod is added before the statement, automatic contains operations are deduplicated.