Add full form data to array builder

[Mottie]

Are you removing, renaming or moving a folder in this PR?

• No, I'm not changing any folders (skip to TeamSites and delete the rest of this section)
• Yes, I'm removing, renaming or moving a folder

Did you change site-wide styles, platform utilities or other infrastructure?

• No
• Yes, and I used the proxy-rewrite steps to test the injected header scenario

Summary

• (Summarize the changes that have been made to the platform)

  In our form, we were trying to implement the array builder pattern but we have a need to access all form data. Currently, the data passed into the array builder pages is scoped and prevent us from displaying necessary info on array item and summary pages.

  This PR contains the necessary platform code changes to get this working. You can pull in 96602-fulldata-testing branch locally, build sc-testing app, and go to the evidence summary page locally to test

• (If bug, how to reproduce)
• (What is the solution, why is this the solution)

  A new fullData parameter is passed into updateUiSchema, updateSchema and summary cardDescription functions.

• (Which team do you work for, does your team own the maintenance of this component?)

  Benefits Decision Reviews

• (If using a flipper, what is the end date of the flipper being required/success criteria being targeted)

Related issue(s)

department-of-veterans-affairs/va.gov-team#96602

Testing done

• Describe what the old behavior was prior to the change
• Describe the steps required to verify your changes are working as expected
• Describe the tests completed and the results

  Added associated tests

• _Exclusively stating 'Specs and automated tests passing' is NOT acceptable as appropriate testing
• Optionally, provide a link to your test plan and test execution records

Screenshots

N/A

What areas of the site does it impact?

Platform array builder functions

Acceptance criteria

Quality Assurance & Testing

• I fixed|updated|added unit tests and integration tests for each feature (if applicable).
• No sensitive information (i.e. PII/credentials/internal URLs/etc.) is captured in logging, hardcoded, or specs
• Linting warnings have been addressed
• Documentation has been updated (link to documentation *if necessary)
• Screenshot of the developed feature is added
• Accessibility testing has been performed

Error Handling

• Browser console contains no warnings or errors.
• Events are being sent to the appropriate logging solution
• Feature/bug has a monitor built into Datadog or Grafana (if applicable)

Authentication

• Did you login to a local build and verify all authenticated routes work as expected with a test user

Requested Feedback

(OPTIONAL) What should the reviewers know in addition to the above. Is there anything specific you wish the reviewer to assist with. Do you have any concerns with this PR, why?

[rhasselle-oddball]

looks great, thanks for adding this

[rhasselle-oddball]

We can also get this data by using getFormData passed into CustomPage. Could just use that, or if still want to introduce this on its own, that seems OK too.

[rhasselle-oddball]

what do you think of also giving this an index? the user would probably have to use window.location.pathname parsing to check if the index is the same, (since our data structure isn't multiple indecies for uiSchema), but maybe useful.