Easier to reason about src file hierarchy

Opening an issue from [this discussion](https://github.com/LemmyNet/lemmy-ui-leptos/pull/55#discussion_r1595506584) as promised. ## Proposed file hierarchy - src - lib.rs - main.rs - constants.rs - host.rs - cookie_middleware.rs - routes.rs - routes - home.rs - home - home_page.rs - login.rs - login - login_page.rs - login_form.rs - post.rs - post - post_page.rs - get_post.rs - layouts.rs - layouts - base_layout.rs - filter_bar_layout - contexts.rs - contexts - site_context.rs - theme_context.rs - common.rs - common - components.rs - components - icon.rs - text_input.rs - unpack.rs - serverfns.rs - serverfns - list_comments.rs - list_posts.rs - utils.rs - utils - derive_query_signal.rs - types.rs ## Digest For simplicity, I didn't list every file that exists in the project. Some things to call out: - Uses newer, more idiomatic style of declaring modules. Refer to [this blurb from the Rust book](https://doc.rust-lang.org/book/ch07-05-separating-modules-into-different-files.html?highlight=mod.rs#alternate-file-paths). This should make it easier to find module styles since there won't be a bunch of files all names `mod.rs` strewn throughout the codebase. - Routes keep modules that are only related to what a given route/page as siblings (e.g. `login_form.rs` and `get_post.rs`, a component and serverfn respectively, listed above) - Went with "Page" as a suffix instead of "Activity". Not a diehard on this change, but I'm unfamiliar with the convention of calling these "activities" instead of "pages", which threw me off at first. ## Things to hash out There are some things I'm still not sure of in this suggestion. For example, in this hierarchy, several serverfns (e.g. vote, save, etc.) are only relevant to one or a few components (vote buttons, content actions). It arguably makes more sense to colocate these with the relevant components instead of throwing them in the common serverfns directory. A similar case can be made for colocating the navbars and the logout serverfn with the `BaseLayout` since they're only ever used there. If we did do this approach, I could see a hierarchy like: - layouts - base_layout.rs - base_layout - base_layout.rs - logout.rs - top_nav.rs - bottom_nav.rs Or perhaps: - layouts - base_layout.rs - base_layout - base_layout.rs - serverfns.rs - serverfns - logout.rs - components.rs - components - top_nav.rs - bottom_nav.rs Thoughts?