deterministic ordering for errors in __all__

[asottile]

Resolves #603

I couldn't figure out a way to test this that wasn't flakey and without writing a bunch of test infra to look at the actual messages (since they're all the same type)

Here's a demo of the fix however:

$ python3 -m pyflakes t.py
t.py:1:1 undefined name 'a' in __all__
t.py:1:1 undefined name 'b' in __all__
t.py:1:1 undefined name 'c' in __all__
t.py:1:1 undefined name 'd' in __all__
$ python3 -m pyflakes t.py
t.py:1:1 undefined name 'a' in __all__
t.py:1:1 undefined name 'b' in __all__
t.py:1:1 undefined name 'c' in __all__
t.py:1:1 undefined name 'd' in __all__
$ python3 -m pyflakes t.py
t.py:1:1 undefined name 'a' in __all__
t.py:1:1 undefined name 'b' in __all__
t.py:1:1 undefined name 'c' in __all__
t.py:1:1 undefined name 'd' in __all__
$ python3 -m pyflakes t.py
t.py:1:1 undefined name 'a' in __all__
t.py:1:1 undefined name 'b' in __all__
t.py:1:1 undefined name 'c' in __all__
t.py:1:1 undefined name 'd' in __all__
$ python3 -m pyflakes t.py
t.py:1:1 undefined name 'a' in __all__
t.py:1:1 undefined name 'b' in __all__
t.py:1:1 undefined name 'c' in __all__
t.py:1:1 undefined name 'd' in __all__

[sigmavirus24]

I wonder if we can drop all_names or if the usage on L1026 is really that much faster just because it's a set in practice on real code-bases

[asottile]

Yeah I thought about this, but I don't really have a good way to profile this. I imagine it's not a significant difference to keep the original value as a list and just do in against that (however it does appear to change this from O(N) + O(M) to O(N * M) where N is the number of imports and M is the number of items in __all__

Probably ok to just leave it since it keeps this change a little bit more minimal

[sigmavirus24]

Non-blocking thought in-line

[asottile]

@sigmavirus24 while I have you, can you click disable in appveyor so we don't get the empty failure?