Reverting toArray call, it is valid to pass in pre-alloc size

[zsmoore]

• Please check if the PR fulfills these requirements

• [N/A] Tests for the changes have been added (for bug fixes / features)
• [ N/A] Docs have been added / updated (for bug fixes / features)

• What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
  Reverts a change in pr Multiple targets in lint runner #40. As per javadocs

https://docs.oracle.com/javase/7/docs/api/java/util/Set.html#toArray(T[])

and If the set fits in the specified array, it is returned therein. Otherwise, a new array is allocated with the runtime type of the specified array and the size of this set.

Passing size is a valid thing to do.

• What is the current behavior? (You can also link to an open issue here)
  Current behavior is the same as

(JsonFile[]) filesToLint.toArray()

• What is the new behavior (if this is a feature change)?
  Array is optimized with same size as needed and no longer makes an unnecessary array of size 0 on each toArray call.

• Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)
  None.

• Other information:

[PawanHegde]

While it is valid to pass in a fixed sized array, it is also just as valid (maybe more?) to pass in a zero-sized array as a type hint when you don't want a larger array. Our intention is to get an array of exactly the same size as the set. Passing 0 ensures this. There are no side-effects as far as it concerns our code. The link you cited also uses the example String[] y = x.toArray(new String[0]); instead of String[] y = x.toArray(new String[x.size()]);.

As far as performance is concerned, new String[0] is faster as I explained in PR #40 despite the JVM needing to create a throwaway empty array. So if you're concerned about performance, us fixing the size of the array will be slower than letting the JVM decide. Not to mention the extra function call to filesToLint.size() (which will also be really fast on an optimized JVM)