Fix Ret. Req. logic to determine cycle for 2PT

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

> Part of the work to replace NALD for handling return requirements

We want to be able to offer users the option to generate return requirements from the licence's abstraction data. On the `/setup` page, they can select this option and the service is expected to generate return requirements using the source abstraction data against the licence.

We added support for this in [Use abstraction data to create return requirements](#1107). But after double checking the test scenarios we've made a mistake in the logic.

We've determined a return requirement will be linked to a purpose that is two-part tariff purely based on the purpose's two-part tariff flag. This effects what collection and reporting cycle we pick for the return requirement.

But the purpose can only be interpreted as two-part tariff if the licence also has a two-part tariff agreement. So, the purpose might be spray irrigation, for example, which is flagged as two-part tariff. But if the licence doesn't also have a two-part tariff agreement we need to ignore that when determining the cycles for the return requirement.

This change fixes our logic in `GenerateFromAbstractionDataService`.