feat: improve templating developer experience

# Improve templating developer experience

This is an issue that would like to emphasise on the developer experience when creating and designing templates using mason.

## Problem

When creating a mason brick, some templated files that use moustache might not be valid anymore. For example, if you're creating a brick that has a Dart file (`.dart`) which uses the moustache syntax, it might no longer benefit from the compilation/lint checks for valid Dart; since the moustache syntax is being considered as part of the file content completely invalidating it as valid Dart.

This makes the experience of developing templates difficult, some of the reasons are:
- The developer can't immediately tell if the generated code has compilation errors or if it follows the analysis options properly.
- The developer can't immediately tell if the moustache syntax has been correctly used.
- The developer can't immediately see what changed on the generation after amending the template file (related to https://github.com/felangel/mason/issues/778#issue-1599798106)

## Proposals

The following is just an enumeration of ideas, they might or might not be mutually exclusive and they might or might not support each other. In other words, there isn't just a single right proposal to be chosen as part of the solution.

### Proposal 1: Hot reload

The idea is to include a command within `mason_cli` (eg `mason watch`) that given a default state (this is: a configuration with the variables, current directory, output directory, etc) it listens to changes in the template file and generates the result whenever any file under `__brick__` changes. The developer can optionally choose if during this generation the pre-gen and post-gen hooks should be applied.

This would improve the developer experience, since the developer can now quickly observe and build an intuition when looking at the output. For example, the developer can split the screen with the current template file to its left and the realtime generated code to its right. Allowing them to immediately see the generated code from the currently modified template. Obviously, the generated code wouldn't have moustache syntax, allowing the compiler and linter to work as expected (solving some of the listed problems above).

### Proposal 2: Moustache syntax and linting

The idea behind this proposal is to make the developer aware whenever invalid moustache/mason syntax is being used in files under `__brick__`.

For example, warning the developer when they forget to close a loop:
```txt
{{#platforms}}
{{.}}
{{/platforms}}

{{#platforms}}
{{.}}
{{platforms}} <-- Invalid, unclosed loop. Propose quick fix to add "/"
```