Add Builder pattern for creating configured Stream factories

[cowtowncoder]

(from FasterXML/jackson3-dev#8)

Although actual mutability of JsonFactory (and subtypes) has not been a significant source of issues (compared to ObjectMapper), same theoretical issue exists, and ideally factories would be immutable to guarantee that users can not try to apply changes that either do not take effect, or even cause problems.

Given that parser/generator features can already be defined at higher level (and passed through API with 2.x, with some improvements planned for 3.x) this is probably not a huge change for JSON factory. There may be more questions on other formats, but even there most changes can already be applied via FormatSchema (for CSV for example).

[cowtowncoder]

Completed work for JSON package itself (commit accidentally referred to mythical issue 443, so not linked).

[cowtowncoder]

So, changes include:

• All TokenStreamFactory instances have
  • static build() method for constructing sub-class of TSFBuilder
  • non-static rebuild() to construct builder with settings of factory (for creating slightly changed versions)

This has allowed making factories 100% immutable, which will then help doing the same for mapper.

[cowtowncoder]

Addendum: now fully immutable all the way through, including fasterxml dataformat modules.

[cowtowncoder]

After some thinking, a new 2.x release, 2.10, will include Builder-style interface too, although implementation can not guarantee full immutability like 3.0 does. The goal here is to make it easier to update 2.x code for eventual migration to 3.0; but there are also actual benefits from improved configurability.

[GedMarc]

Yes for 3.x,
Should not implement builder pattern 1.6 though (only valid up till jdk 6), should implement CRP (JDK 7 and up).
e.g. no static inner classes with build, type safety with inheritance support on it's own instance. If adding new functionality, use the up-to-date pattern?
Also much, MUCH, better for JPMS.

[cowtowncoder]

@GedMarc Just to make sure: changes for 2.10 are included, so jackson-core will use that as an option -- but former mutable approach still works. So in case Java 6 has issues (I think I did find some problem with overload, generic types), that should be fine as long as the only problem would be inability to use builders (as they are optional).
With 3.x there will only be builder way, except for 0-arg constructor (for backwards compatibility).