FE: Create new related work items on new work item page

Once #483099 (closed) is complete, we should update the CreateWorkItem form component to check for a related_item query parameter in the page's URL.

If present, we can treat it as if it's the relatedItem prop, and allow the user to create a new work item while relating it to another.

This feature will be used if the user clicks the 'full-page' button in the create-work-item modal. The page we navigate to will be the 'new work item' page, and we can use the query parameter to preserve the relatedItem context from the modal.

Acceptance Criteria

• After clicking the 'new related [item]' option in the action menu, clicking the 'open in full page' button in the create work item modal must persist the related item from the modal when viewed in the full page view.
• The full page view with a 'related item' set must behave exactly the same as creating a new work item does within the modal view.

Implementation Considerations

• The CreateWorkItemModal component contains the logic for navigating to the full 'create work item' page as well as the 'related item' data.
• We can use these two features to ensure, if present, the 'related item' data is included in the url query when navigating to the full page view.
• The CreateWorkItemPage component can parse the related item data from the URL and, if present, can pass the data into the CreateWorkItem form component via it's relatedItem prop.

The 'related item' data we currently use is made up of an id, type (work item type), and reference. These are contained within an Object. We could add a query parameter for each part (related_item_id, related_item_type, and related_item_reference) or combine them all together into one related_item parameter (probably base64 encoding the data too).

On one hand, keeping the items separate makes it possible to read in the browser nav bar and in logs and potentially make it easier to edit. It's not clear whether we would want anybody to manually edit these URL parameters though, as this could lead to misleading behaviour.

Combining the items into one parameter and encoding it should help ensure the data isn't tampered with and prevent the user from seeing misleading information on the page (e.g. a message saying the new item will related to #45 when it will actually relate to #55).

Another consideration is that we only need the id of the item we want to relate the new item to. The reference and type are just there to display to the user and could be considered lower importance. We could use just one query param, related_item_id, and use a GraphQL query to fetch the type and reference once the page has loaded, using the id to query for the correct data. This will result in marginally worse performance, as we'll need to wait for an extra query before we can render the form (if the url query param is present), but would result in a cleaner URL, if that's something we find important.