Centralize and harden identification of pool component types

There are a number of places in the code where what we do depends on what kind of inputs were put into a particular pool (for example, is the pool in question an amplicon plate pool, where the inputs are 16s library prep compositions? or is it an amplicon sequencing plate, where the inputs are (amplicon plate) pool compositions? or is it a shotgun plate pool, where the inputs are shotgun library prep compositions?) Unfortunately, the checking for this information has been implemented in several different ways in several different places, and not always robustly. This should be centralized and hardened. This work absolutely MUST be done before we add support for any new protocols to the software!

Here are locations I know about that examine pool components and make decisions based on what they find:

1) PoolComposition.get_components_type
https://github.com/jdereus/labman/blob/a5308e9c26a0344fd30e1c0c5e50c9a7d212fbef/labcontrol/db/composition.py#L1070-L1087

Used in PoolingProcess.generate_pool_file

https://github.com/jdereus/labman/blob/46241e448edd4fc615aeea914e8dd80bf88aad79/labcontrol/db/process.py#L2594-L2595

Note that the get_components_type method only checks the first component in a pool but has a check in place to make sure it errors if there is more than one kind of component in a pool (see #267 ).

2) SequencingProcess.create

https://github.com/jdereus/labman/blob/46241e448edd4fc615aeea914e8dd80bf88aad79/labcontrol/db/process.py#L2709-L2725

This code ALSO only checks the first component in a pool, but unlike `get_component_type`, lacks a check to ensure that there is not more than one component type per pool, which led to issue #498 (which has been fixed by making it not possible to create such a pool through the interface anymore but not by correcting this code). Looks like the code here should probably actually use `get_component_type` instead of doing its own check.

3) util.py's get_pools_listing

https://github.com/jdereus/labman/blob/46241e448edd4fc615aeea914e8dd80bf88aad79/labcontrol/db/util.py#L27-L30

This is used by PoolListHandler.get:

https://github.com/jdereus/labman/blob/a5308e9c26a0344fd30e1c0c5e50c9a7d212fbef/labcontrol/gui/handlers/pool.py#L41-L42

This one is not like the others in that it is looking at the pool component compositions' description strings to determine their types instead of looking at the pool component compositions' object type. I believe this is not for an intentional reason but just because it was written at a different time than the other approaches.