Deregister partially replaced multi-output plugins

[JelleAalbers]

What is the problem / what does the code in this PR do

Bad things happen if plugin A registers to make X and Y, then B registers to make just X.

For example, strax will first say B is producing X, as it should. Then you ask who is producing Y, it will say A. But now ask again who is producing X -- strax changes its mind and says A is producing X!

This happens because these 'partial registrations' break the assumptions of the plugin caching system. But that won't be all: if we actually tried to make Y the Processor shouldn't be smart enough to make two X's and throw away the bad one. Even if it was, would a user asking for X and Y really expect them to come from two different plugins?

Can you briefly describe how it works?

This PR ensures a plugin is completely deregistered once another plugin is registered to provide one of its outputs instead. In the example above, A would be completely deregistered and datatype Y would be no longer available in the context as soon as B registers to produce X.

Can you give a minimal working example (or illustrate with a figure)?

Surprisingly this happens in several places in straxen/cutax. For example:

import cutax
st = cutax.xenonnt_online()
st._get_plugins(['raw_records'], '026195')

gives

{'raw_records': Fake1TDAQReader,
 'raw_records_diagnostic': Fake1TDAQReader,
 'raw_records_aqmon': Fake1TDAQReader}

which makes no sense, Fake1TDAQReader is an ancient plugin. We only register it temporarily, then overwrite it with the actual DAQReader. However, it is still registered for raw_records_diagnostic, which does not exist in nT. When cutax asks for the lineage of raw_records_diagnostic on intialization, the plugin cache becomes polluted. If you actually try to make raw_records with this context, or even just do storage conversion, you will not go to space today.

A similar thing happens for straxen's PeakletClassificationSOM (registers for som_peaklet_data and peaklet_classification, then another plugin takes over peaklet_classification) and several neutron veto cut plugins in cutax (all produce cut_coincident_events_nv as well as another datatype that varies per plugin).

[coveralls]

coverage: 91.472% (+0.01%) from 91.458%
when pulling f7edfe2 on JelleAalbers:fix_multioutput_deregistration
into a9d4ebb on AxFoundation:master.

[WenzDaniel]

Thanks @JelleAalbers looks fine.