DRAFT: convert user-post-pages to new pattern demo

[hnb-ku]

This draft PR is an example of a proposed new pattern that we can use to make theming the app easier.

The idea here works like this

1. There's almost 0 changes to the style or logic here. It's mostly about getting the same result with a slightly different pattern.
2. It removes all styling and logic from the route's +page.svelte file. We should try to keep most of the non-client-side login in the +page.server.ts file and pass the data down.
3. We add a components folder inside each route. In it, we define as many parts as possible that the route needs, but we try to keep them closer to a "view" side and less on the logic side.
4. If a "component" is very similar, and is used in a bunch of different places, we'll move it to $lib and make it even more reusable.
5. In this demo, we keep tailwind styling to reduce the review/explanation surface.
6. All of those put together will enable us to have a system where individual components can be themeable.

As far as theming goes, the super long-term goal is to keep most things CSS based, but also allow a certain (but tightly controlled option to override "templates". To be clear though, CSS-only theming is 80% of our focus for now.

A theme can be a simple, scoped CSS file, or it can also define "views"

The two guard-rails for us are

1. CSS changes are "safe" if they are done by site-admins
2. if you want to override a "template" you have the default data available to you, and you can add your own on top if needed.

This means that

1. Weird "core" can move fast without having to worry about breaking themes
2. If you do add a "template" override, it's up to you to keep up. (we can of course have tooling and communication in place to make this easier)

The TL;DR here is this

1. At the very highest level, site admins can add a single theme.css thing to override colors, spacing and so on.
2. One level below that is overriding specific component templates to move things around
3. At the very lowest level, that can override the entire Page.svelte component for a route. We provide the same "data" we use in core, but they're free to add more stuff as needed.
4. I don't support any theming-related changes to a route's +page.server.ts file for now. It's a problem that doesn't need to be solved.

If this pattern is OK for us, we can split the work into multiple stages.

1. Convert routes (one route per-PR) to the new pattern with the same logic and tailwind styling
2. Pull out any "frequently" used components with a lot of similarities to the $lib folder
3. Establish the default theme
4. Investigate CSS theming options

[hnb-ku]

Closing this draft in favor of tracking the goals here #187