Fix empty reusable maps in ThreadPool

[wvpm]

The ThreadPool created empty vectors:
memory::FixedVector<fixed_point_t> reusable_country_map_0 { country_keys.size() };
They have a fixed capacity but a size of 0. Subsequent indexing was out of bounds.

This PR fixes that by forcing you to either use FixedVector::create_empty(capacity) or specify a way to initialise the values.
The name create_empty is chosen to avoid accidental empty vector creation.

[Spartan322]

Suggested change

	FixedVector static create_empty(const size_t capacity) { return FixedVector(capacity); }
	static FixedVector create_empty(const size_t capacity) { return FixedVector(capacity); }

But honestly why did you need to add a static initializer function when you could've just added FixedVector(const size_t, T const&), its not like there is anything ambiguous about explicit FixedVector(const size_t)'s use, it also violates the expectations with std::vector.

[wvpm]

Creating an empty FixedVector is an edge case. We only need that for the IndexedFlatMap so it can validate keys before filling the vector.

The IndexedFlatMap has a constructor that takes in the keys only and generates the values for you.
The code in ThreadPool used to work like that but was rewritten to directly use the FixedVector. The similarity between the constructors allowed the bug to happen.

It's best to make a special create_empty method to avoid such issues.

[Spartan322]

Then this isn't a drop-in replacement for std::vector and can't be used in the same place as vector, in which case it shouldn't be called a vector, the constructor follows the same behavior as std::vector, you have to worry about this exact same issue with std::vector because its about capacity, not size, that should be expected, it doesn't even make sense really to supply a capacity for a constructor without a value since that would be encouraging the use of UB anyway, also its not empty, its pre-allocated.