Decouple refactorings from babel

[nicoespeon]

When I started the project, I wasn't too familiar with the AST and babel's capabilities. I did the trade-off of relying on babel's interface to implement the refactorings faster.

That works, but it will be an issue in the long run.

We'd better introduce our own abstractions for the AST. We started doing that with the ast module, but it's still very tied to babel.

There would be a few benefits of doing so:

• make it easier to upgrade babel (we're stuck on an old version because of types: Bump @babel/types from 7.9.0 to 7.13.0 #256)
• make it possible to switch babel for another parser when convenient (e.g. use TS compiler when relevant, it provides nice features that babel doesn't)
• build a higher-level API that would simplify refactorings code and make it easier to implement more ambitious refactorings

Because we have so much code tied to it, it won't be an easy task. Hopefully, this is something we can do gradually.

I've been thinking about this for months and I think it's the main refactoring that will benefit the project in the mid-long term.

[nicoespeon]

Less of a priority, I was able to finally upgrade babel: #375

It could be nice to have a higher-level API and be able to switch the parser. But I think we may do that as part of supporting refactoring across files (we may use typescript parser instead).

I also started to build richer functions on top of babel with the ast module. The good news is that it's a proxy, so the rest of the code doesn't depend on babel directly. Although we still inherit a lot of babel interfaces and we could refactor implementation details behind higher-level interfaces…

In any case, it's not a clear win to spend time on this without a concrete feature 👐