Add Natrix the static analysis tool for Vyper contracts

[s3bc40]

We should add Natrix to Moccasin, it could be a great addition to analyze and identify issues in Vyper contracts.

https://albertocentonze.github.io/natrix/

@AlbertoCentonze even prepared for an addition to the framework by implement _obtain_default_paths with moccasin lib path.

https://github.com/AlbertoCentonze/natrix/blob/main/natrix/ast_tools.py#L64-L82

Natrix versions are tied to a specific Vyper version, but a full support for 0.4.x is under development.

@PatrickAlphaC anything to keep in mind or to prepare between the tools?

[PatrickAlphaC]

WOAH

This is sick! Does it make sense to add it to moccasin natively? I feel like maybe we are bloating moccasin... Even the formatted could have been too far... We are making it very opinionated... Although... I often like that... idk... maybe it's good!!!

[s3bc40]

I think we are following the footsteps of foundry with forge fmt and forge lint. But yeah, in general, we need to consider if it's worth it to add a tool to the framework or just point to it in the documentation, like a specific "Nice to have" section.

I do not have much experience in maintaining a framework, so I'll follow the wise and technical words. I still need to step up on the performance domain etc...

Good news is the latest of Natrix now support >=0.4.* so we are not tied to a specific release of vyper (for now): https://github.com/AlbertoCentonze/natrix/releases/tag/v0.1.9

At least having effective linter and formatter is good to have 🤔

[AlbertoCentonze]

FWIW I'm also working on a flattener that will come with Natrix.

If you build an extension system for Moccasin I'll be happy to support it so that people can opt in and the framework doesn't get too bloated by default.

[s3bc40]

That seems like something fascinating to make into moccasin: a global extension system for future Vyper tools.

We keep the core functionalities for simple mox projects, but let an opening door for external tools to improve the framework power. So we do not bloat the framework, and it doesn't ask a direct maintenance for moccasin.

Bonus: if our system is general enough, other developers could build around moccasin (new features and enhancement) before considering adding a feature as a core functionality.

Idk if I went too fars, I am just trying to understand with my own xp. Am I right in my process of thinking?

[s3bc40]

#161 could be related to make a main plugin cmd with subcmd like add or run