Display of supplier order unit in data sent to suppliers

[lentschi]

Currently supplier order units are always rendered in reference to the group order unit.

We might want to change that, so supplier order units are not rendered in reference to the group order unit, if the rendered data is intended for external use (e.g. "order fax" - Group order unit is a field that's to be used inside of foodcoops only.)
TODO: Unclear how to go about this. Options mentioned so far (also see discussion in foodcoops/foodsoft_hackathon#66):

1. Always list all the ratios down to the first SI conversible unit. (Con: Leads to very long, overly verbose unit descriptions such as Pallet (100 box x 4 parcel x 10 package x 50 g))
2. Introduce a new user-configurable article version db field supplier reference unit that is used to determine in reference to which SI unit external exports should be done. (Con: Effort implementing it and continuous effort maintaining the fields content for foodcoop users)
3. Break down the supplier order unit to the first SI conversible unit. For deeply nested ratios this could lead to large numbers - e.g. Pallet (200000 g). To come by this issue one could use the user defined list of default units to find the unit with the smallest possible integer conversion and then render it as Pallet (200 kg) instead. (Con: Effort implementing; kind of unexpected that the list of default units should have an impact on how the data is exported.)
4. Do not change anything (Maybe this issue is not worth the effort and other measures can be used for disambiguation - e.g. changing the article name. Currently it's not possible to add the exact same article name twice anyway - unless maybe... see this discussion: Article name duplication prevention #1227)

[lentschi]

Moved this issue to a discussion, as for me it's not clear which path to take.

[lentschi]

Options 2 + 3 (user-configurable article version db field) have been downvoted by @yksflip, @twothreenine and @mjavurek.

More feedback is very welcome. If none is given, we'll stick with 4 (no change) for 5.0.