Explore the possibility of writing a linter to accompany cargo-near

[itegulov]

There are some common SDK usage mispatterns that we could prevent if we had a linter. Here are a few examples I could think of:

1. Exposing SDK storage collections as a part of a contract API. Everything compiles fine as the collections implement BorshSerialize, but the result is not what users expect (does not actually hold serialized data, only the prefix). This is hard to catch on the #[near_bindgen] side as collections might be inside of structs/enums outside of the macro scope (also no semantical information makes it hard to follow type references).
2. Check that you never instantiate two collections with the same prefix. From what I have seen usually the prefix is known statically, so we could catch a lot of errors at compile time.
3. Encourage using env::panic_str/env::abort instead of panic! to avoid including formatting toolchain in the resulting wasm file.
4. More generally, encourage using the Result-based error handling pattern
5. Do not include non-public functions in an impl section that is marked with #[near_bindgen] as this is a security concern.

We could potentially use https://crates.io/crates/dylint to base our linter on. I personally have no prior experience with it, but it seems promising.