Capacity improvements for internal structures

[johnjaylward]

Key Changes:

• Updates array constructor and bulk operations to best guess capacity information
• Update JSONObject to allow best guess for initial capacity for internal operations

What problem does this code solve?
For some operations for JSONArray and JSONObject we already know the end-capacity of our internal structures, however, we grow them dynamically instead. This change reduces dynamic growth operations by providing capacity information ahead of time for certain operations.

Risks
low. If anything, this should be improvements for both CPU and memory for the cases effected by the change.

Changes to the API?
One new protected constructor added to JSONObject to allow specification of the internal hashmap capacity. I didn't feel this was valid as a public constructor as it exposes implementation details of the underlying structure.

Will this require a new release?
No, can be rolled into the next release

Should the documentation be updated?
No

Does it break the unit tests?
No test cases failed on the current master.

Was any code refactored in this commit?
Yes

Review status
ACCEPTED Starting 3 day window

[MinnDevelopment]

Better to use an if/else statement here instead of 0 as initial capacity

[johnjaylward]

My thought was that if you pass null, you are probably trying to create an empty JSONArray. But for backwards compatibility it may be better to use the standard capacity. Personally if I'm using this constructor it's because I've already finalized my object somewhere else and I'm just preparing it for serialization. But that generalization may not be what we want to imply.

I'll go ahead and change it.

[stleary]

Looks like a reasonable enhancement, though most users will not likely notice a difference, Don't see a need for additional tests in this case. Starting 3 day window.