Final UI Layout Refactor

Modularize `LibraryBrowser.tsx` to be less monolithic, aim for a higher separation of concerns between each of the constituent components. This may involve the creation of several additional files in the directory `frontend/src/components`, to align more closely with the Single Responsibility Principle (from SOLID).

Configure `LibraryBrowser.tsx` such that it conforms with the new designs drafted in the group chat. Provide space for the new Materials menu and the (to-be-configured) floor map visualizer, and generally tidy up the main dashboard's interface.

Here are some images which will be referenced during the design process, the final configuration will manifest as a thoughtful combination of the two designs depicted. Priority will be given to the aspects of the designs which most closely align with LibMaster's final set of functional and non-functional requirements. These may be found below the diagrams:

## Initial Drafted Design by Dylan (@dylantcon)

## Initial Drafted Design by Ivan (@Kupinaaa)

## Functional Requirements
### Student Functional Requirements
1. The system shall authenticate users with FSU credentials through either a confirmation to the student’s e-mail, or via the system-wide Duo authentication provider from Cisco. (HIGH)
2. The system shall allow booking an available study room based on the grad statuses (HIGH)
3. The system shall display available study rooms in an interactive floor-map layout. (HIGH)
4. The system shall allow filtering rooms by capacity, floor, library, and time availability. (HIGH)
5. The system shall display a user’s upcoming reservations with room details and time information. (HIGH)
6. The system shall allow users to cancel their existing reservations. (HIGH)
7. The system shall provide a timeline visualization of current and future room availability on a per-library and per-library-floor basis. (HIGH)
8. The system shall enable search functionality for the library’s loanable items. (MEDIUM)
9. The system shall allow users to report issues with rooms or equipment. (MEDIUM)
10. The system shall save user booking preferences for expedited future reservations. (LOW)
11. The system shall send confirmation emails for successful reservations. (LOW)
12. The system shall notify users when their reservation has been canceled by an administrator. (LOW)
### Administrator Functional Requirements
1. The system shall allow controlling the groups of users including Graduate Students (HIGH)
2. The system shall allow marking a room a grad room (HIGH)
3. The system shall allow administrators to mark individual rooms as unavailable due to maintenance. (HIGH)
4. The system shall display past, current, and upcoming room reservation records with student information. (HIGH)
5. The system shall enable administrators to override or cancel existing bookings. (HIGH)
6. The system shall provide functionality to update multiple room statuses simultaneously. (MEDIUM)
7. The system shall enable the management of the library supply inventory. (MEDIUM)
8. The system shall allow tracking and responding to student-submitted issue reports. (MEDIUM)
9. The system shall provide adjustment capabilities for maximum reservation time limits, on a per-library, per-library-floor, and per-library-floor-room basis. (MEDIUM)
10. The system shall track equipment rental analytics and identify frequently unavailable items. (LOW)
11. The system shall provide booking analytics for space optimization and staffing decisions. (LOW)
## Non-functional Requirements
1. **Usability**: The system shall provide an intuitive interface requiring no training for students to make reservations. The system should also make errors clear to the user so that they can act accordingly.
2. **Performance**: The system shall load floor maps and room availability data in no more than three seconds.
3. **Responsiveness**: The system shall function properly on mobile devices, tablets, and desktop computers.
4. **Security**: The system shall protect user data and prevent unauthorized access to administrative functions.
5. **Reliability**: The system shall prevent double-booking of rooms for any overlapping time intervals, and shall gracefully resolve simultaneous identical room reservation requests.
6. **Accessibility**: The system shall comply with WCAG 2.1 AA standards for web accessibility.
7. **Maintainability**: The system shall employ a modular architecture to facilitate future enhancements and maintenance.
8. **Availability**: The system shall be available 24/7 with scheduled maintenance windows not exceeding 4 hours per month.
9. **Compatibility**: The system shall work correctly in modern web browsers (Chrome, Firefox, Safari, Edge, etc).
10. **Data Integrity**: The system shall maintain accurate reservation data even during concurrent booking attempts.