docs: fix contributor docs links and typos (#18637)

## Summary

This PR fixes several small documentation issues in the contributor and
setup guides:

- fixes broken docs links in the root README
- corrects multiple typos and capitalization issues in contributor docs
- fixes malformed Markdown for the Redis command in local setup
- improves wording in the Docker Compose self-hosting guide

## Changes

- updated README installation links to the current docs routes
- changed `Open-source` to `open-source`
- fixed `specially` -> `especially` in the frontend style guide
- normalized `MacOS` -> `macOS`, `powershell` -> `PowerShell`, and
`Postgresql` -> `PostgreSQL`
- replaced the invalid `localhost:5432` Markdown link with inline code
- fixed the malformed fenced code block for `brew services start redis`
- cleaned up Redis naming/capitalization and a few grammar issues in the
setup docs
- improved the warning and environment-variable wording in the Docker
Compose guide

## Testing

- not run; docs-only changes

---------

Co-authored-by: Charles Bochet <charlesBochet@users.noreply.github.com>

packages/twenty-docs/developers/contribute/capabilities/frontend-development/style-guide.mdx

@@ -9,7 +9,7 @@ The goal here is to have a consistent codebase, which is easy to read and easy t
 
 For this, it's better to be a bit more verbose than to be too concise.
 
-Always keep in mind that people read code more often than they write it, specially on an open source project, where anyone can contribute.
+Always keep in mind that people read code more often than they write it, especially on an open source project, where anyone can contribute.
 
 There are a lot of rules that are not defined here, but that are automatically checked by linters.
 
@@ -150,7 +150,7 @@ type MyType = {
 
 ### Use string literals instead of enums
 
-[String literals](https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#literal-types) are the go-to way to handle enum-like values in TypeScript. They are easier to extend with Pick and Omit, and offer a better developer experience, specially with code completion.
+[String literals](https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#literal-types) are the go-to way to handle enum-like values in TypeScript. They are easier to extend with Pick and Omit, and offer a better developer experience, especially with code completion.
 
 You can see why TypeScript recommends avoiding enums [here](https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#enums).
 
@@ -288,4 +288,3 @@ An Oxlint rule, `typescript/consistent-type-imports`, enforces the no-type impor
 Please note that this rule specifically addresses rare edge cases where unintentional type imports occur. TypeScript itself discourages this practice, as mentioned in the [TypeScript 3.8 release notes](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-8.html). In most situations, you should not need to use type-only imports.
 
 To ensure your code complies with this rule, make sure to run Oxlint as part of your development workflow.
-