Adds support for multiple templates directories (almost) no breaking changes

From #158 discussion:

I think that's the best approach. We won't need hygen to discover templates at all if we can tell it where all of them are :)

Here's my suggestion for a new templateLocations (or for a templates)
type templates = string | Array<string | {
    path: string;
    prefix?: string;
}>
What about conflicts?

If two locations have generators with the same name and using the same prefix, there will be a conflict and it needs to be resolved. But first...

Why handle conflicts instead of forcing uniqueness via prefix?

It allows for a very powerful mechanism that promotes reusability. Imagine there's an awesome template package that does a lot, but I want to replace one of its generators. Instead of forking it, understanding its code, and modifying it, I can simply add a generator to my project and setup hygen to use

Proposed solution

Instead of trying to come up with clever algorithms that will be confusing and take ages to get right (as in any package manager ever), let's just let the user decide what to do.

Specifically, suggest the addition of another property to .hygen: conflictResolutionStrategy. The property value would be an enum with 3 possible values:

fail: [default] stops the generation and lets the user know that templates are in conflict, and it needs to pick a strategy

override: keeps the template that appears last in the array

skip: keeps the template that appeared first skipping the ones that conflict

I think this strategy should be fairly easy to implement. In the future, a custom strategy may be added to allow specifying a function that takes 2 template paths and returns a map of their paths to { name: string, prefix: string } for the templates.

btw, sorry if this was already proposed. I looked but didn't find it anywhere.

jondot / hygen

Adds support for multiple templates directories (almost) no breaking changes #442

What about conflicts?