This patch addresses two issues I found while looking into a problem yesterday. First, SBTarget::AddModule calls Target::GetOrCreate which will find the module in the global module list, the current target, and will call the DebugSymbols framework on macOS and look in specified directories, and do a Spotlight search of the local computer. But it doesn't call Symbols::DownloadObjectAndSymbolFile() with a "force expensive lookup" which we should assume the program is trying to do if they gave us a UUID to look up. This matches the behavior of target modules add -u .... today in the lldb command line interface.
Also, if the SB API user has created a Target which has no architecture, we normally will set the Target's arch as soon as we find a hint about the arch -- e.g. when we connect to a gdb remote serial protocol stub, or when we get a corefile. But in this case, they are creating a Target with no arch, adding a module to it. We should use the same scheme where a Target inherits the first likely ArchSpec we see when it has none of its own.
Add a test for these two things, using a fake dsym-for-uuid.sh shell (which Jonas has pointed out in the past, I really need to create a utility function that creates these given an array of uuid/binary/dsyms, which I agree with but haven't done yet. :/)
nit: add a comment next to true to indicate that it's for copy_executable