style: Add prettier pre-commit hook (#2031)

There are 2 things to know about prettier:
- it's quite pretty most of the time
- it's not configurable

CONTRIBUTING.md

@@ -1,7 +1,9 @@
 # Contributing
+
 Thank you for your interest in contributing to the `clio` project 🙏
 
 To contribute, please:
+
 1. Fork the repository under your own user.
 2. Create a new branch on which to commit/push your changes.
 3. Write and test your code.
@@ -14,26 +16,29 @@ To contribute, please:
 > **Note:** Please read the [Style guide](#style-guide).
 
 ## Install git hooks
+
 Please run the following command in order to use git hooks that are helpful for `clio` development.
 
-``` bash
+```bash
 git config --local core.hooksPath .githooks
 ```
 
 ## Git hooks dependencies
+
 The pre-commit hook requires `clang-format >= 19.0.0` and `cmake-format` to be installed on your machine.
 `clang-format` can be installed using `brew` on macOS and default package manager on Linux.
 `cmake-format` can be installed using `pip`.
 The hook will also attempt to automatically use `doxygen` to verify that everything public in the codebase is covered by doc comments. If `doxygen` is not installed, the hook will raise a warning suggesting to install `doxygen` for future commits.
 
 ## Git commands
+
 This sections offers a detailed look at the git commands you will need to use to get your PR submitted.
 Please note that there are more than one way to do this and these commands are provided for your convenience.
 At this point it's assumed that you have already finished working on your feature/bug.
 
 > **Important:** Before you issue any of the commands below, please hit the `Sync fork` button and make sure your fork's `develop` branch is up-to-date with the main `clio` repository.
 
-``` bash
+```bash
 # Create a backup of your branch
 git branch <your feature branch>_bk
 
@@ -43,18 +48,20 @@ git pull origin develop
 git checkout <your feature branch>
 git rebase -i develop
 ```
+
 For each commit in the list other than the first one, enter `s` to squash.
 After this is done, you will have the opportunity to write a message for the squashed commit.
 
 > **Hint:** Please use **imperative mood** in the commit message, and capitalize the first word.
 
-``` bash
+```bash
 # You should now have a single commit on top of a commit in `develop`
 git log
 ```
+
 > **Note:** If there are merge conflicts, please resolve them now.
 
-``` bash
+```bash
 # Use the same commit message as you did above
 git commit -m 'Your message'
 git rebase --continue
@@ -62,27 +69,30 @@ git rebase --continue
 
 > **Important:** If you have no GPG keys set up, please follow [this tutorial](https://docs.github.com/en/authentication/managing-commit-signature-verification/adding-a-gpg-key-to-your-github-account)
 
-``` bash
+```bash
 # Sign the commit with your GPG key, and push your changes
 git commit --amend -S
 git push --force
 ```
 
 ## Use ccache (optional)
+
 Clio uses `ccache` to speed up compilation. If you want to use it, please make sure it is installed on your machine.
 CMake will automatically detect it and use it if it is available.
 
 ## Opening a pull request
+
 When a pull request is open CI will perform checks on the new code.
 Title of the pull request and squashed commit should follow [conventional commits specification](https://www.conventionalcommits.org/en/v1.0.0/).
 
 ## Fixing issues found during code review
+
 While your code is in review, it's possible that some changes will be requested by reviewer(s).
 This section describes the process of adding your fixes.
 
 We assume that you already made the required changes on your feature branch.
 
-``` bash
+```bash
 # Add the changed code
 git add <paths to add>
 
@@ -95,6 +105,7 @@ git push
 ```
 
 ## After code review
+
 When your PR is approved and ready to merge, use `Squash and merge`.
 The button for that is near the bottom of the PR's page on GitHub.
 
@@ -102,55 +113,63 @@ The button for that is near the bottom of the PR's page on GitHub.
 > **Note:** See [issues](https://github.com/XRPLF/clio/issues) to find the `ISSUE_ID` for the feature/bug you were working on.
 
 # Style guide
+
 This is a non-exhaustive list of recommended style guidelines. These are not always strictly enforced and serve as a way to keep the codebase coherent.
 
 ## Formatting
+
 Code must conform to `clang-format` version 19, unless the result would be unreasonably difficult to read or maintain.
 In most cases the pre-commit hook will take care of formatting and will fix any issues automatically.
 To manually format your code, use `clang-format -i <your changed files>` for C++ files and `cmake-format -i <your changed files>` for CMake files.
 
 ## Documentation
+
 All public namespaces, classes and functions must be covered by doc (`doxygen`) comments. Everything that is not within a nested `impl` namespace is considered public.
 
 > **Note:** Keep in mind that this is enforced by Clio's CI and your build will fail if newly added public code lacks documentation.
 
 ## Avoid
-* Proliferation of nearly identical code.
-* Proliferation of new files and classes unless it improves readability or/and compilation time.
-* Unmanaged memory allocation and raw pointers.
-* Macros (unless they add significant value.)
-* Lambda patterns (unless these add significant value.)
-* CPU or architecture-specific code unless there is a good reason to include it, and where it is used guard it with macros and provide explanatory comments.
-* Importing new libraries unless there is a very good reason to do so.
+
+- Proliferation of nearly identical code.
+- Proliferation of new files and classes unless it improves readability or/and compilation time.
+- Unmanaged memory allocation and raw pointers.
+- Macros (unless they add significant value.)
+- Lambda patterns (unless these add significant value.)
+- CPU or architecture-specific code unless there is a good reason to include it, and where it is used guard it with macros and provide explanatory comments.
+- Importing new libraries unless there is a very good reason to do so.
 
 ## Seek to
-* Extend functionality of existing code rather than creating new code.
-* Prefer readability over terseness where important logic is concerned.
-* Inline functions that are not used or are not likely to be used elsewhere in the codebase.
-* Use clear and self-explanatory names for functions, variables, structs and classes.
-* Use TitleCase for classes, structs and filenames, camelCase for function and variable names, lower case for namespaces and folders.
-* Provide as many comments as you feel that a competent programmer would need to understand what your code does.
+
+- Extend functionality of existing code rather than creating new code.
+- Prefer readability over terseness where important logic is concerned.
+- Inline functions that are not used or are not likely to be used elsewhere in the codebase.
+- Use clear and self-explanatory names for functions, variables, structs and classes.
+- Use TitleCase for classes, structs and filenames, camelCase for function and variable names, lower case for namespaces and folders.
+- Provide as many comments as you feel that a competent programmer would need to understand what your code does.
 
 # Maintainers
+
 Maintainers are ecosystem participants with elevated access to the repository. They are able to push new code, make decisions on when a release should be made, etc.
 
 ## Code Review
+
 A PR must be reviewed and approved by at least one of the maintainers before it can be merged.
 
 ## Adding and Removing
+
 New maintainers can be proposed by two existing maintainers, subject to a vote by a quorum of the existing maintainers. A minimum of 50% support and a 50% participation is required. In the event of a tie vote, the addition of the new maintainer will be rejected.
 
 Existing maintainers can resign, or be subject to a vote for removal at the behest of two existing maintainers. A minimum of 60% agreement and 50% participation are required. The XRP Ledger Foundation will have the ability, for cause, to remove an existing maintainer without a vote.
 
 ## Existing Maintainers
 
-* [godexsoft](https://github.com/godexsoft) (Ripple)
-* [kuznetsss](https://github.com/kuznetsss) (Ripple)
-* [legleux](https://github.com/legleux) (Ripple)
-* [PeterChen13579](https://github.com/PeterChen13579) (Ripple)
+- [godexsoft](https://github.com/godexsoft) (Ripple)
+- [kuznetsss](https://github.com/kuznetsss) (Ripple)
+- [legleux](https://github.com/legleux) (Ripple)
+- [PeterChen13579](https://github.com/PeterChen13579) (Ripple)
 
 ## Honorable ex-Maintainers
 
-* [cindyyan317](https://github.com/cindyyan317) (ex-Ripple)
-* [cjcobb23](https://github.com/cjcobb23) (ex-Ripple)
-* [natenichols](https://github.com/natenichols) (ex-Ripple)
+- [cindyyan317](https://github.com/cindyyan317) (ex-Ripple)
+- [cjcobb23](https://github.com/cjcobb23) (ex-Ripple)
+- [natenichols](https://github.com/natenichols) (ex-Ripple)