Refactor and add wildcard support

[aeijdenberg]

This PR is in two parts. The first part (first commit) refactors the {find,replace,remove}_op.go code so that the logic that descends lives with the individual token types which are split into separate files.

The second part (second commit) adds the ability to match all elements in an array, and thus be able to add / replace many objects with a single replace op.

Appreciate your consideration - this is a first cut - happy to massage it as needed if the community thinks this would be useful.

Fixes #8.

[aeijdenberg]

It occurred to me it would be pretty easy to add prepend support at the same time, so I added a commit and test for that, which I think fixes #6.

[cppforlife]

@aeijdenberg the reason behind how it's currently structured is that i wanted to keep each operation self contained ie i should be able to add an operation without having to change anything about pointers. conceptually pointer could be pulled out as a separate library and should not know anything about processing operations. additionally im not sure it's actually easier to understand what operation does by looking across different tokens instead of in a single loop. i could see some kind of code sharing between them outside of tokens themselves but i think there needs to be a clear boundary around tokens and processing logic.

[aeijdenberg]

@cppforlife I'd be willing to try again with the existing structure. I needed to make a degree of structural change as iterating down the list of tokens wouldn't adapt easily to matching more than one element.

There's probably an easy enough way to do it with a stack instead of recursive descent - I'll have a look - it might make the patch easier to review.

I guess it's a trade-off between keeping operations self-contained, vs keeping token logic self-contained. e.g. after the initial refactor, adding token_wildcard.go and token_prepend.go was trivial.

Let me know your thoughts.

[aeijdenberg]

Added alternate implementation here.