Rename and update return requirement scenarios (#141)

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](DEFRA/water-abstraction-system#1431).

cypress/e2e/internal/returns-requirements/cancel-returns.cy.js → cypress/e2e/internal/return-versions/cancel-returns.cy.js

@@ -57,7 +57,7 @@ describe('Cancel a return requirement (internal)', () => {
     cy.get('.govuk-fieldset__heading').contains('How do you want to set up the requirements for returns?')
 
     // click set up manually and continue
-    cy.get('#setup-4').check()
+    cy.get('#method-4').check()
     cy.contains('Continue').click()
 
     // confirm we are on the purpose page

cypress/e2e/internal/returns-requirements/copy-existing.cy.js → cypress/e2e/internal/return-versions/copy-existing.cy.js

@@ -57,7 +57,7 @@ describe('Submit returns requirement using copy existing (internal)', () => {
     cy.get('.govuk-fieldset__heading').contains('How do you want to set up the requirements for returns?')
 
     // choose copy from existing requirements and continue
-    cy.get('#setup-2').check()
+    cy.get('#method-2').check()
     cy.contains('Continue').click()
 
     // confirm we are on the existing requirements page

cypress/e2e/internal/returns-requirements/returns-required.cy.js → cypress/e2e/internal/return-versions/returns-required.cy.js

@@ -57,7 +57,7 @@ describe('Submit returns requirement (internal)', () => {
     cy.get('.govuk-fieldset__heading').contains('How do you want to set up the requirements for returns?')
 
     // click set up manually and continue
-    cy.get('#setup-4').check()
+    cy.get('#method-4').check()
     cy.contains('Continue').click()
 
     // confirm we are on the purpose page

cypress/e2e/internal/returns-requirements/start-by-using-abstraction-data.cy.js → cypress/e2e/internal/return-versions/start-by-using-abstraction-data.cy.js

@@ -57,7 +57,7 @@ describe('Submit returns requirement (internal) using abstraction data', () => {
     cy.get('.govuk-fieldset__heading').contains('How do you want to set up the requirements for returns?')
 
     // choose the start by using abstraction data checkbox and continue
-    cy.get('#setup').check()
+    cy.get('#method').check()
     cy.contains('Continue').click()
 
     // confirm we are back on the check page