Make excludes take precendence over includes.

[craftmaster2190]

Expected behavior: specific excludes should override broad includes (and vice-versa)

<enunciate ...>
  ...
  <api-classes>
    <include pattern="com.mycompany.**"/>
    <exclude pattern="com.mycompany.ExceptThisClass"/>
    <!-- ^^^ This class should be explicitly excluded ^^^ -->
  </api-classes>
  ...
</enunciate>

Actual behavior: (includes both broad and specific take precedence over excludes)

<enunciate ...>
  ...
  <api-classes>
    <include pattern="com.mycompany.**"/>
    <exclude pattern="com.mycompany.ExceptThisClass"/>
    <!-- ^^^ This class is still included anyway. ^^^ -->
  </api-classes>
  ...
</enunciate>

I just mentioned this on: https://github.com/stoicflame/enunciate/wiki/Excluding-Including-Classes

So merging this PR would invalidate that new documentation.

I think this PR provides a minor improvement to how includes and excludes are used.

Future Discussion: I think long-term; a more appropriate behavior (less violating of the Principle of Least Astonishment) would be for exact names (a.b.C) to have priority over Ant patterns (a.b.**)

I think the ideal include/exclude paradigm would look like: Sources:

com.mycompany.A
com.mycompany.B
com.mycompany.C
com.othercompany.A
com.othercompany.A
com.othercompany.C

Config:

<enunciate ...>
  ...
  <api-classes>
    <include pattern="com.mycompany.**"/>
    <exclude pattern="com.mycompany.C"/>
    <exclude pattern="com.othercompany.**"/>
    <include pattern="com.othercompany.C"/>
  </api-classes>
  ...
</enunciate>

Results in

com.mycompany.A
com.mycompany.B
com.othercompany.C

(unless of course they were explicitly referenced in a class and picked up that way.)

[stoicflame]

Thanks for the PR. If you rebase on the latest, I'll be happy to merge it.