Refactor DetermineBillingPeriods to use type

https://eaflood.atlassian.net/browse/WATER-4403

We want our Billing & Data team to be able to generate supplementary bill runs all year round. However, at the moment they have to enforce a manual 'stop' on them until annual bill runs are completed. This is because of the 2 ways the engine operate.

Annual just bills for the current charge versions. It doesn't look at replaced charge versions or what was previously billed. supplementary does do these things. So, if the order is 'Annual -> Supplementary' then the bill will be correct. For example, supplementary calculates a debit of a £100 for a charge version (the licence was flagged for 'reasons'!) but sees the £100 debit from the annual bill. They cancel each other out so the customer sees nothing.

If the order was `Supplementary -> Annual` though, annual doesn't look back at previous transactions. It would just generate another debit to the customer for £100 leading to them being billed twice.

We could guarantee annual bills were raised on April 1 we wouldn't have a problem. However, because of the additional work that goes into preparing them and then validating the what the engine generates it can take some time. That leaves a window where a supplementary could be raised and the charges for a customer get messed up.

This has always been the case and billing & data have just had to deal with it by not generating supplementary. But that in itself causes problems because then bills start backing up that could be sent out.

So, this year we intend to solve the problem. We are going to amend our supplementary billing engine so that it will check if an annual bill run for the same region has been raised in the current billing period. If it has we'll carry on as usual. If it hasn't, we'll move the financial year end back to the first year where one was raised. This will allow B&D to crack on with supplementary bills, at least for previous years and prevent charging data being messed up.

The first step to achieving this is to refactor `DetermineBillingPeriods` to always expect a `year` and a `billRunType`. It can then use this information to generate the billing periods accordingly, rather than always from the current billing period.

> How we determine the financial end year for a supplementary bill run will come in later changes.