Improve Submissions integration UI

[3mcd]

This PR:

• makes the unjournal seed script aware of local dev environments (the submissions integration will now link to localhost:3002 properly)
• makes integrations load instance configuration (if any) and user info from the root layout
• adds a bunch of shadcn components and uses them in the submissions integration
• adds a new @pubpub/sdk/react entrypoint that exports a few useful boilerplate components for integrations

Most changes are cosmetic, but I would like opinions on fetching data from the root layout, because I'm not sure if that's a good idea or not.

Issue(s) Resolved

N/A

Test Plan

1. Go through the test plan in Early Submissions integration #69 on your local machine (the review app works but you have to mess with the URLs). Everything should work the same as in Early Submissions integration #69, but it looks better now!

Screenshots (if applicable)

[3mcd]

Fixed some typical key warnings.

[3mcd]

I was able to get tailwind working with dependencies by resolving absolute paths of the packages.

[3mcd]

This might not be the best approach, but after a few hours of research, this seems like the only/best way to reliably get search parameters in layout components.

[isTravis]

I think the reason Next makes doing this clunky is because they're trying to enforce that if your layout needs to know search params, there's something funky in the route architecture. Since layouts apply to all children (e.g. /, /blog, /blog/1) - they're suggesting that it would be funky to have that top level layout consistently require search params all the way down (as opposed to say, using those params at the appropriate /page.tsx and doing any necessary fetch there).

I understand why you've implemented the approach as you did here, but I can see Next's point too. Perhaps we could load something like /authenticate/page.tsx which reads the search params, and then sets a cookie/localStorage before redirecting to / so that intra-app links aren't required to pass searchParams around forever.

I've fought with Next about this before, and in the end almost always decided that Next was right — and if I thought I needed searchParams in layout.tsx as opposed to page.tsx I was deviating from the intended use of layout and page files.

That said, if it's working - it's working :) And I know there's a deadline, so pure code alignment with Next's opinions doesn't need to be first priority.

[3mcd]

That makes sense. Thanks for the insight. We've talked about using a cookie anyways, so I'll take a stab at the page approach!

[isTravis]

I think it'd be fine to merge this with the middleware approach. That could always be refactored at a later date. It seems the higher priority is just getting the functionality pushed forward.

If you can see the refactor you'd want to make now though, of course go for it, but I don't think any of the code structure as is should be a blocker for merging.