Rename and update return requirement scenarios

[Cruikshanks]

https://eaflood.atlassian.net/browse/WATER-4257
DEFRA/water-abstraction-team#126

Part of the work to migrate managing returns from NALD to WRLS

When we first started working on creating and managing 'requirements for returns,' 'requirements' was the term used in all conversations.

So, we used it as the root URL for all related endpoints. However, things started getting confusing when we realised that, depending on the context, 'return requirements' can mean two different things.

Within the app and amongst the team, it is a general term that refers to all the details needed to determine how and when a licensee should submit their returns: the 'requirements for returns'.

In the code and database, it means the child record of a 'return version'. The return version holds the start and end dates of when the requirements apply and why they were created. But the child 'return requirements' hold the details used to generate the return logs that licensees will submit against.

When you go through the set-up journey, you are not creating a new return requirement; you're creating a new return version and all its child return requirement records. When you click a 'Requirement for returns' entry in the UI, the view is not of a return requirement but of a return version and all its child return requirement records.

We've fallen into the same trap as the legacy code of confusing our naming. As the journey sets up a new return version, /return-versions should be the root. The same goes for GET /return-versions/a8a0dbbd-f7bf-47c0-887f-c4e9ad43ab52 to view a return version.

This is a housekeeping change to rename the scenarios and ensure they work after the changes to water-abstraction-system.