Make feelin a peer dependency

[Skaiir]

What should we do?

Ideally we should not have a hard dependency on feelin. Switching over to peer dependency should be the right thing to do here

Why should we do it?

There are multi angles here, but first and foremost, feelers is a templating structure built around feelin, not a direct consumer of it. It in theory should work for any somewhat similarly structured expression language. It certainly should always work with newer versions of feelin. We mainly rely on feelin for the syntax highlighting which again, is feelin's business not this library's. Furthermore, the scenarios in which we (and presumably others) use this library often have us depending on feelin as well directly.

So, in the interest of simplicity, I think we should just move this to a peer dependency, check this doesn't cause any issues in integrations and just stop having to worry about version matches and such.

[nikku]

@Skaiir Another angle to consider here:

Can we ensure that feelin is going to be used anyway, wherever feelers is used? If that is the case, it is fine to be a peer dependency (or no dependency at all).

If that is not the case then we can resort to de-duplication being done by bundlers. They do a great job at that, nowadays.