chore: refactor async app routes to factory

[shon-button]

No card, just cleanup.

🚀 Impact:

• Refactored async app route pages to use bciers/libs/components/src/nextPageFactory/defaultPageFactory.tsx
• Refactored over nested "non-async" page routes that imported client component
• Removed unnecessary "non-async" wrapper components that imported client components

📝 Notes:

• The "non-async" page routes, that import client component that use useEffect to load data, should be refactored to follow the pattern of the app route page using Suspense to load an async SSR component to load data that is then passed to the client form, using defaultPageFactory.tsx Ticket

[pbastia]

Thanks for tackling this, quite a bit of an uplift! 🥇
I've left some comments about the use of the defaultPageFactory that apply to most pages refactor - we'll need to make sure:

• that the Next app page params (version_id, facility_id, etc) align with the props of the page components, otherwise the page factory won't know what to map
• that we handle the seachParams case in a consistent way where they're needed (either flatten them, or add them in their own prop)

[pbastia]

The defaultPageFactory uses generic typing to forward the type of the params object to the component props, so we can use it right out of the box here too. they just need to be

export default defaultPageFactory(FacilityReviewForm);

[pbastia]

Also, how about building a syncPageFactory, or have an async=false optional param in that default factory?

[pbastia]

the defaultPageFactory doesn't forward the searchParams yet, we'll need to add them if they're needed

[pbastia]

the AdditionalReportingDataPage component expects a versionId but Next is setup to set version_id.

I suggest making the AdditionalReportingDataPage component (and all the other ones) extend the HasReportVersionor HasFacilityId interfaces where applicable, to guarantee compatibility

[pbastia]

the defaultPageFactory won't know how to resolve the ActivityPage props from the params object.
This one is probably the most complex, we can maybe determine how we want to handle the params vs searchParams for every page to be consistent