Allow multiple output streams from one technology about calliope HOT 3 CLOSED

There are a number of ways in which the YAML file could look following the introduction of this, including (assuming the technology produces heat and power):

1. in the same capacity as rb, in which there are a set of cb constraints defining heat output. Here allow_cb would be disabled on False and a string when used (i.e. heat in this case).
2. carrier_2 is defined in the line following carrier. In this case only one other constraint would be defined: the percentage of carrier_2 produced when carrier is produced (i.e. heat to power ratio).
3. list arrays for certain YAML values, such that carrier = power becomes carrier = [power, heat] and subsequent constraints are dealt with in the same fashion or there is simply a heat to power ratio which is required when defining more than one carrier. This could allow an infinite number of carriers to be defined, which may be useful. As a result, the heat to power ratio constraint (htp) could then also be a list, following the number of carriers defined.
4. Define a dummy technology which consumes no resources and has an additional constraint to force it to follow the output of the primary carrier. This requires the least change in the current code, but puts the onus on the user to understand how to use the fix, and could be misused easier.

I've attached a YAML file with each example applied. Far from exhaustive, would welcome other thoughts on it.

Currently it doesn't allow one technology to consume a resource and decide the degree to which it will produce the respective carriers, which might be useful (imagine the case where CSP produces electricity from heat but may decide that hot water is a more useful provision at a given point).

from calliope.

I think option 3 would be best, followed by option 2 or perhaps 1, but if the added flexibility of option 3 is not necessary at the moment, it may not be worth the added effort to implement.

If option 3 is implemented other parts of configuration could potentially be generalized too: source_carrier, which defines the carrier consumed by a conversion technology, and perhaps secondary resource (``rb`)?

from calliope.

This will be dealt with in the same fashion as for issue #9, in which the multiple outputs and inputs will be defined in the yaml file, turning the source_carrier and carrier into dicts rather than simple strings. Expected in version 0.5.0

from calliope.