feat: split company page layout into multiple tabs 💼

[Wisesofthemall]

Description ✏️

Closes #536

Describe what this PR does.

• Bullet points are helpful.
• Screenshots are helpful, if applicable.

Type of Change 🐞

• Feature - A non-breaking change which adds functionality.
• Fix - A non-breaking change which fixes an issue.
• Refactor - A change that neither fixes a bug nor adds a feature.
• Documentation - A change only to in-code or markdown documentation.
• Tests - A change that adds missing unit/integration tests.
• Chore - A change that is likely none of the above.

Checklist ✅

• I have done a self-review of my code.
• I have manually tested my code (if applicable).
• I have added/updated any relevant documentation (if applicable).

[tomas-salgado]

@Wisesofthemall I'm curious to hear reasoning for why we should have each of the parts of this page (employees, reviews, etc.) into separate pages? My initial thought was that since there isn't really too much data it's fine to implement this issue by just making a change in a single file where we just only render whatever section is selected (so even if all the data is loaded, we only show a section of it at a time for ease of use). Just curious to hear if you considered this, and which approach you think might be better here!

[Wisesofthemall]

@Wisesofthemall I'm curious to hear reasoning for why we should have each of the parts of this page (employees, reviews, etc.) into separate pages? My initial thought was that since there isn't really too much data it's fine to implement this issue by just making a change in a single file where we just only render whatever section is selected (so even if all the data is loaded, we only show a section of it at a time for ease of use). Just curious to hear if you considered this, and which approach you think might be better here!

Given the example listed (Recap page), that page uses separate pages to render specific pieces of data, so I was just following that logic. Additionally, with the use of separate pages, I'm utilizing Server-Side Rendering (SSR) as opposed to Client-Side Rendering (CSR), and here are the benefits:

Improved Performance: SSR can reduce the initial load time, especially for users on slower networks, as the content is pre-rendered on the server.

SEO Benefits: Pages rendered on the server are better optimized for search engines, which can improve the visibility of the content.

Scalability: As data grows, separating sections into different pages can help keep each page lightweight and maintain performance.

[Wisesofthemall]

But of course, I can refactor to Client Side Routing if its necessary

[tomas-salgado]

Great work @Wisesofthemall! I've tested this all locally and it's working great. I initially had thought client-side rendering would be fine, but by implementing server-side rendering you are making it much easier for future developments on this page!

The one thing is that there are merge conflicts on one of the files, though I believe this is because of some new code that was added to that file during the big Opportunities feature Rami just built. We just need to make sure not to lose that code, and then this will be all good!

[ramiAbdou]

Great work here, @Wisesofthemall!

I made a couple of updates to bring this home:

1. Consolidated the past/current employees page into 1 (that was my bad @tomas-salgado, I might've told you to separate those pages).
2. We'll automatically redirect to the employees page if there are no reviews. This is mainly to avoid showing empty information as much as possible (let me know if you disagree here).
3. Now that we're splitting the routes server-side, we'll no longer need to fetch all that information in the initial /companies/:id layout. So I removed those!

This is going to enable much more company-specific information development soon (ie: compensation data and more 👀👀)!

i made changes