Introduce FE lib/logger for errors

• Introduce FE lib/logger for errors
• Log hello message in browser console
• Add logging docs to FE guide

What does this MR do?

This MR introduces a ~/lib/logger module and a simple logError function which will be the standard for client-side logging of errors. Currently, we just have a number of places where we console.error with a eslint-disable. Having a single function for this will help us control and promote logging errors.

Other potential benefits:

• Improved control of testing for logError in tests vs. console.error
• Improved control for how we want to observe the logError events. We want client-side logging to be complete and helpful, but we might only want to observe a sample of these.

Screenshots or Screencasts (strongly suggested)

How to setup and validate locally (strongly suggested)

This MR refactors a recent console.error addition to a Deploy Freeze enhancement (see !66331 (merged)) to use logErorr.

To test this error logging:

1. Open the CI/CD settings for a project (e.g. /gitlab-org/gitlab-shell/-/settings/ci_cd)
2. Open the browser's console and open the "Network" tab
3. Scroll to Deploy freezes and insert a new deploy freeze (if one doesn't exist already)
4. In the browser's developer network tab, find the request used to insert / fetch the deploy freeze (api/v4/projects/2/freeze_periods). Block the URL of this request (found by right clicking the request).
5. Click the trash icon next to the newly added deploy freeze.
6. The request should fail since the URL was blocked and an error will be logged to the console.

Does this MR meet the acceptance criteria?

Conformity

• I have included changelog trailers, or none are needed. (Does this MR need a changelog?)
• I have added/updated documentation, or it's not needed. (Is documentation required?)
• I have properly separated EE content from FOSS, or this MR is FOSS only. (Where should EE code go?)
• I have added information for database reviewers in the MR description, or it's not needed. (Does this MR have database related changes?)
• I have self-reviewed this MR per code review guidelines.
• This MR does not harm performance, or I have asked a reviewer to help assess the performance impact. (Merge request performance guidelines)
• I have followed the style guides.
• This change is backwards compatible across updates, or this does not apply.