feat(hooks): project persistent hooks

[Archez]

PR Checklist

• The PR title follows our guidelines: https://github.com/NativeScript/NativeScript/blob/master/CONTRIBUTING.md#commit-messages.
• There is an issue for the bug/feature this PR is for. To avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it.
• You have signed the CLA.
• All existing tests are passing: https://github.com/NativeScript/nativescript-cli/blob/master/CONTRIBUTING.md#contribute-to-the-code-base
• Tests for the changes are included.

What is the current behavior?

Because the hooks folder in a NS project is not meant to be checked into source, and is cleared with ns clean, there is no easy way to have project persistent hooks aside from creating a local node_module plugin that registers the hook.

What is the new behavior?

These changes enable specifying project hooks in the nativescript.config.(ts|js) file and the cli will detect the configuration during hook events (before/after). I borrowed the same hook config syntax that plugins specify in their package.json for simplicity.

Just add the following config to enable project persistent hooks for your app.

export default {
  id: 'org.nativescript.app',
  main: 'app.js',
  hooks: [
    {
      type: 'after-prepare', // one of the hook events
      script: 'scripts/some-script.js', // can be any path in the project
    },
  ],
};

Fixes/Implements/Closes #5576.

There is greater discussion in this issue regarding a better way to organize plugin hooks, but I only attempted to just permit project persistent hooks within the current hook flow.

[NathanWalker]

A very humble thank you 🙏 ☺️

[rigor789]

Awesome PR, thanks!

One small suggestion is to use the second parameter for defaultValue when using getValue (typings may be off - missing the second param, I pushed a fix to them yesterday).

The other one is to scope the hooks array under the cli object. This one I'm not 100% sure about, but in #5596 we added the packageManager option under the cli scope since we plan to extend this to more options in the near future - and it's nice to group CLI overrides/function under a single key. However, hooks are arguably a CLI thing, but also tightly coupled to a project, so it may be fine to leave it at the root level.

Thoughts on this are welcome! (now that I typed this, I'm leaning towards a root hooks array like you've done - reverted my suggestion)