Refactor code to use go/types instead of go/ast

[ernesto-jimenez]

On issue #18 I mentioned that Go 1.5's go/types package I stated that the change should allow simplifying the codebase.

I wanted to see how much work it would mean so I did a quick implementation from scratch using go/types.

The implementation results in ~24% less and the following bugs are fixed: #18 #19 #40

% wc -l $(ls **/*.go | grep -v _test | grep -v fixtures)
      57 main.go
     174 mockery/generator.go
      99 mockery/importer.go
      40 mockery/imports.go
      39 mockery/method.go
     409 total
% wc -l $(ls **/*.go | grep -v _test | grep -v fixtures)
     197 cmd/mockery/mockery.go
       4 doc.go
     254 mockery/generator.go
      81 mockery/parse.go
     536 total

[evanphx]

I don't really want to make mockery go 1.5 only. How do we avoid doing that and using go/types?

[ernesto-jimenez]

@evanphx before adding go/types to the stdlib there was golang.org/x/tools/go/types, but there are some API differences and we can expect go/types to have a stable API since it's in the stdlib.

Since it's a command-line tool, would it be enough to cross-compile the tool and publish the binaries for people with Go < 1.5?

[dwlnetnl]

Maybe it's a matter of time to deprecate Go < 1.5 support.

[colonelpanic8]

@ernesto-jimenez 's suggestion to release binaries seems good to me...

[arvenil]

What about now, since go 1.6 is already here could you reconsider dropping support for go < 1.5? :D
I would like to avoid switching to fork, but looks like it fixes at least 2 big issues with mockery so it kind of looks like a waste to ignore such a nice contribution to library.
And for go < 1.5 people can always use older hash of library.

[evanphx]

Let's do this! Time to move on now that most everyone is on 1.5.

[evanphx]

It's done! It's in! Thanks so much for the idea and code to get started @ernesto-jimenez!