small unit::xp_color() optimisation

We now call get_modification_advances() once (instead of twice). In particular get_modification_advances() can be a rather slow operation for a unit that has many [advancement]s. and xp_color() is called rather often from the drawing code.

In fact xp_color() has caused annoying slowdowns in the past for a certain umc campaign that adds many dummy ( this means: blocked via require_amla by default) [advancement]s to units types. (this was also the reason for 4d73031 where i found that a lot of temporary t_string objects were created during xp_color/get_modification_advances while investigating that). (that was before the second call to get_modification_advances() was added but well, better to call it once than twice if we know that calling it once was already problem in the past, i even considered caching he result of get_modification_advances() in the past but i currently don't think that's needed anymore, in particular since umc authors have now better options that addong tons of dummy [advamcent]s to unit_types)

src/units/unit.cpp

@@ -1148,8 +1148,10 @@ color_t unit::xp_color() const
 
 	color_t color = normal_color;
 	bool major_amla = false;
+	bool has_amla = false;
 	for(const config& adv:get_modification_advances()){
 		major_amla |= adv["major_amla"].to_bool();
+		has_amla = true;
 	}
 	if(advances_to().size() ||major_amla){
 		if(near_advance){
@@ -1159,7 +1161,7 @@ color_t unit::xp_color() const
 		} else if(far_advance){
 			color=far_advance_color;
 		}
-	} else if(get_modification_advances().size()){
+	} else if(has_amla){
 		if(near_advance){
 			color=near_amla_color;
 		} else if(mid_advance){