Minimise allocations for ModifierSum

[wvpm]

CountryInstance::contribute_province_modifier_sum is called for each province (expect 10s-100s per country). Every call to ModifierSum::add_modifier_sum called reserve_more, which is defined as:

    constexpr void reserve_more(reservable auto& t, size_t size) {
        t.reserve(t.size() + size);
    }

This resulted in repeated allocations, possibly reallocating the country's modifiersum for each controlled province.
Instead we now first sum the extra size for all provinces and then resize (not reserve!) once.
We use resize instead of reserve as it uses the underlying growth algorithm that typically reserves extra room, avoiding reallocating because of 1 extra element.

Resize creates empty elements which are later replaced. The ModifierSum keeps track of the count of valid elements and uses this for its size().

[schombert]

As a general note, calling reserve explicitly is typically only an optimization if you can find a one-time upper bound on the possible growth and thereby call reserve once instead of allowing the vector to grow naturally. However, if you call reserve repeatedly you run the risk of performing much worse than the vector's normal exponential growth. The growth factor of the vector is designed so that adding elements is amortized O(1). Repeated calls to reserve that grow the vector only by some amount that we can place an upper bound on (as presumably happens here, since the total number of possible modifiers is bounded) makes the entire process (cycles of reserve + element additions) amortized O(n). In your particular case, a little back of the napkin math will show that just allocating space for every country to have every possible modifier times the number of land provinces is within the memory budget, so you can use that as the value for a single reservation and be very, very unlikely to ever need to grow the vectors.

[wvpm]

I'll add unit tests and then we can merge.