Fix multiple issues with properties and top level variables

[jcollins-g]

Fixes #1394. @Hixie Splits the Accessor class into InheritableAccessor (for Class) and Accessor (used directly for TopLevelVariable), rewiring various parts of the object model and factories to better suit the new structure. This includes generating Fields/TopLevelVariables from Accessors rather than the other way around.

This doesn't fix everything for fields (TODOs added noting possible problem areas), but fixing any other problems should be substantially easier with this refactor.

Of particular note is the workaround for FieldElement only containing the current class's explicit getter in a case of an inherited, explicit setter (or vice versa), here. If there's no good reason why the FieldElement from analyzer fails to contain that, perhaps we can change it. @bwilkerson ?

Another similar problem is worked around here -- two different synthetic FieldElements in a weird inheritance corner case where Dartdoc has to pick one to represent the field. The hack here is somewhat arbitrary but wouldn't be necessary if synthetic FieldElements took inheritance into account.

Browseable examples:
old:
http://jcollins1.pdx.corp.google.com:8013/flutter/painting/FlutterLogoDecoration-class.html
new: (path change is due to how I built this as part of my testing)
http://jcollins1.pdx.corp.google.com:8014/painting/FlutterLogoDecoration-class.html

[bwilkerson]

Of particular note is the workaround for FieldElement only containing the current class's explicit getter in a case of an inherited, explicit setter (or vice versa), here. If there's no good reason why the FieldElement from analyzer fails to contain that, perhaps we can change it.

The primary reason for the current implementation, as unfortunate as it is, has to do with parenting. Consider the following example:

class A {
  void set x(int x) ...
}
class B extends A {
  int get x ...
}

If we created a single FieldElement to represent the (x, x=) pair, which class would we choose to be the parent? Either way, one of the property accessors appears to be defined in the wrong class. And if the classes are in different compilation units or libraries, then the problem only gets worse.

I honestly think the right solution is to not create synthetic FieldElements at all and to provide an API that will do the appropriate searching when we need to locate the "paired" accessor. But that's a bigger change than I can take on right now (and one that might be impacted by the move to the new front end).

[jcollins-g]

That's quite reasonable -- and I think your proposed future direction is in line with the direction dartdoc took for this problem (deriving Fields from Accessors). In dartdoc, we have that extra layer of abstraction that at least enables us to paper over it for now -- each analyzer element can have different enclosing classes depending on where we are looking from -- so we don't run into a hard wall.

[bwilkerson]

Just an idea: Some of the code might be cleaner if you allowed e to be null and simply returned null. It would eliminate the need for a fair number of null checks. It's also consistent with some of the other factories.

[jcollins-g]

TODO added, will try for this in a followup. To really do this right, the library construction also has to change to allow for this too as most places where we're calling ModelElement.from from also construct the library.

[bwilkerson]

Remove the commented out code?

[jcollins-g]

Done