(This is a separate issue from #47 despite the similar title, hence the rename.)

This was requested by @Psymon-Prime in a PM. Plugins have a list of masters in the MAST subrecord of the TES4 header record that is used by the game to map form IDs to the master that they're from. The order of these masters has no impact on gameplay, but it does indicate what order they were in when the plugin was created in the CK/CS/GECK, or in third-party programs like xEdit. This doesn't tell us anything useful for mods that only have vanilla masters as masters (other than that the author might've had them in the wrong order) or that only have vanilla masters & another mod, but it could be useful for mods that have multiple other mods as masters. For instance, the author of a patch between two mods might expect the two mods to be sorted in a specific order to allow one mod to win conflicts that aren't covered in the patch. Not all patches are built in a manner agnostic to load order (i.e., such that all conflicts are resolved within the patch itself), so this list of masters could be used to inform how we sort mods patched in this way. We often do this when manually reviewing patches, but I imagine that it could also be done automatically.

For the implementation, I think we should make this a soft rule with less priority than group rules but more priority than overlap rules. If two plugins are being patched, it should be safe to assume that the patch's author has used their judgement to sufficiently maximize the impact of the patched plugins & that we should defer to their judgement (or our own via hard or group rules if absolutely necessary) rather than LOOT's algorithm for overlap rules.

One problem I can see with this mechanism is the possibility for the same plugins to appear in the master lists of multiple other plugins but in different orders relative to each other. In such a case, if these rules aren't already overridden by higher priority ones, we should probably either fall back to overlap & then tiebreak rules or prioritize the master list of the later-loading plugin. The latter would obviously complicate sorting as we'd need to know where those plugins with the master lists that we're looking at are sorted relative to each other in the middle of a sort operation, so the former should be sufficient.