The various GetSharedModule methods have an optional out parameter for
the old module when a file has changed or been replaced, which the
Target uses to keep its module list current/correct. We've been using
a single ModuleSP to track "the" old module, and this change switches
to using a SmallVector of ModuleSP, which has a couple benefits:
- There are multiple codepaths which may discover an old module, and this centralizes the code for how to handle multiples in one place, in the Target code. With the single ModuleSP, each place that may discover an old module is responsible for how it handles multiples, and the current code is inconsistent (some code paths drop the first old module, others drop the second).
- The API will be more natural for identifying old modules in routines that work on sets, like ModuleList::ReplaceEquivalent (which I plan on updating to report old module(s) in a subsequent change to fix a bug).
I'm not convinced we can ever actually run into the case that multiple
old modules are found in the same GetOrCreateModule call, but I think
this change makes sense regardless, in light of the above.
When an old module is reported, Target::GetOrCreateModule calls
m_images.ReplaceModule, which doesn't allow multiple "old" modules; the
new code calls ReplaceModule for the first "old" module, and for any
subsequent old modules it logs the event and calls m_images.Remove.