Bugfix: fix color factor resolution

When resolving a color factor multiplying a vertex,
SARAH`sumOverNonAbelianIndizes[] sums over internal color indices only
if there are two rotated fields and two unrotated fields coupling
together.  ResolveColorFactor[] in Vertices.m now checks for this
condition to reproduce the result by SARAH.
Do not hard code internal color index range

ResolveColorFactor[] in Vertices.m obtains the range of an internal
color index from SARAH`Particles.  For a color octet running in the
loop for instance, the range now becomes from 1 to 8 instead of from 1
to 3 which used to be hard coded.  However, this introduces a
discrepancy between FlexiSUSY and SARAH in the coupling Cp[USd[{gO1}],
conj[USd[{gO2}]], conj[SOc], SOc] which is generated in MRSSM.  The
reason is that a color index in SARAH`sumOverNonAbelianIndizes[] is
always from 1 to 3, returned by SARAH`getIndexRange[].  This issue
needs to be resolved.
meta/Vertices.m: simplify color index range lookup
Merge branch 'development' into bugfix-color-factor
Check color structures of SARAH`Cp[] objects

Ensure that all the SARAH`Cp[] objects that need explicit color
summation have the field arguments in the correct order: the first two
entries must be external fields.

From: Jae-hyeon Park <jae.park@uv.es>
Subject: Re: Missing color summation for 4-SOc vertex
To: Florian Staub <fnstaub@th.physik.uni-bonn.de>
Cc: Alexander Voigt <Alexander.Voigt@physik.tu-dresden.de>
Date: Wed, 19 Mar 2014 17:53:33 +0100 (5 days, 23 hours, 39 minutes ago)

[snip]

> For the moment I did a rather easy fix: I check if none of the four
> particles is a rotated state. In this case I assume that the  "last
> two" states are running in the loop and I sum over their color. (One
> can to this since the quartic couplings are not used anywhere else but
> for the loops).  That convention must, of course, be used later on in
> the loop calculations as well.
>
> That should work for all models delivered with SARAH. Of course, the
> case that two different scalars which are colored are present which
> appear only in one generation (i.e. couplings of the form X X^* Y Y^*)
> would need to declare two different couplings, one with sum over the
> color of X the over Y. That's not yet supported, but I'm not sure if
> your procedure would catch this case?

I believe that our procedure would find the right color indices to
contract since it always checks whose self energy it is: if it is Y's
self energy, X's colors are summed over, and likewise for the other
case.

If I understand the scheme you explained above correctly, it is
then important to distinguish between

    Cp[X, conj[X], Y, conj[Y]] and Cp[Y, conj[Y], X, conj[X]]

since they are different objects representing different color
contractions.

[snip]
Bugfix: generalize color summation routine

1. FS now selects color indices (not) to contract, not by the forms of
the associated generation indices (which are not available if there is
only a single generation), but by comparing each field inside
SARAH`Cp[] with f where f is from SelfEnergies`FSSelfEnergy[f, __].
This enables color summation for instance of Cp[SOc, conj[SOc],
conj[SOc], SOc].

2. FS now sums over one color index common to the two fields being
contracted (as SARAH 4.1.0 does).  For contraction of color triplets,
this leads to the same result as the previous implementation which did
double summation over two independent color indices.  For color
octets, the results differ.  The new implementation makes more sense.
The result still needs to be checked.
Merge branch 'bugfix-color-factor' into development
Update ChangeLog