feat: use helm as a libary instead of copying code

[qvalentin]

This change would include the official helm code as a dependency instead of copying only the code used for linting etc. to this project.

I would really like to get your input @mrjosh on such a design decision. Other people are also welcome to the discussion.

Advantages:

• Less code in this repo that is hard to maintain
• New lints would be added
• We could include more features interacting with helm directly in the future

Disadvantages:

• Larger binary size (went from 49M to 74M) without compression and to 29M using upx
• Possible breaking changes when updating (adding enough tests should avoid this)

[qvalentin]

This would revert https://github.com/mrjosh/helm-ls/pull/14

[qvalentin]

Using helm as a library does not seem uncommon, quite a lot of projects do this: https://github.com/helm/helm/network/dependents?package_id=UGFja2FnZS0yMjY3Mjg4NjYw

[mrjosh]

Hi @qvalentin thanks for the info regarding using helm-core as library.

By leveraging the Helm code directly, we inherently reduce the overhead associated with maintaining a separate, potentially divergent codebase. This shift not only streamlines our development process but also ensures that we benefit from the latest improvements and features added to Helm, keeping our project up-to-date and robust.

Regarding the concerns about the increased binary size and potential breaking changes, these are valid points. However, the reduction in binary size with compression to 29M is quite efficient, and by prioritizing thorough testing, we can mitigate the risks of breaking changes effectively. This proactive approach in testing will safeguard our project's stability and reliability.

[qvalentin]

Thanks for your opinion, I will take this as a approve for the proposed changes and will make it ready to be merged soon.