refactor: use espree instead of esprima for parsing the code as an AST

[zachnthebox]

espree is an Esprima-compatible JavaScript parser.
It looks to be drop in replacement for the work being done in this addon.

This addon prevented our team from transitioning to native classes in Ember Octane because of the dependency on esprima.

[ffaubry]

Our project is entirely Octane and we are using this Addon as it.
Could you be more specific about the issue you found?

[ggayowsky]

While I am not the creator of this PR, I can say that our project needed to fork this repo and use espree as opposed to esprima because there was a dependency that made use of some valid ES8 syntax that esprima could not parse without throwing an error (this problem I believe jquery/esprima#1927).

Since esprima seems to be effectively dead, having this add-on depend on esprima instead of espree, can prevent an app from including some libraries.

[ffaubry]

IMO, this is not related to Octane. ArcGIS Dashboard has been ported to Octane and Esri JSAPI 4.x.
We had no issue. We are using native classes and decorators.

I think @ggayowsky is pointing in the right direction. It's the use of the stage 2/3/4 features of JS that could cause an issue as esprima is very conservative.
We could argue that these stage 2/3/4 features are not supposed to be used in production but things became greyish and devs started to use them, even VS Code is exposing them. Where is the limit? We will address these requests on a cost/benefit way.

I'm putting this out there for future reference.

As for this PR, I will go ahead and merge it. Thx to @zachnthebox for your help.

[ggayowsky]

@ffaubry Problem is that exprima doesn't support features that are in the ECMA spec (it isn't even just stage 2/3/4 features anymore), which is the real problem here.

See the issue I linked in my above comment

[ffaubry]

@ggayowsky Woah.