Add support for "contextual class names and sub-packages"

[q-src]

We have a lot of complex schemas consisting of many objects and sub-objects. There are many sub-objects which are very similar and therefore have properties which are named the same.

See also the following example (dummy schema):

{
  "type": "object",
  "properties": {
    "someProperty": {
      "type": "object",
      "properties": {
        "someSubProperty": {
          "type": "string"
        }
      },
      "format": "translatable"
    },
    "anotherProperty": {
      "type": "object",
      "properties": {
        "someProperty": {
          "type": "object",
          "properties": {
            "anotherSubProperty": {
              "type": "string"
            }
          }
        }
      }
    }
  }
}

At the moment, jsonschema2pojo will generate the classes com.example.TheClass (root object), com.example.SomeProperty, com.example.SomeProperty_ and com.example.AnotherProperty.

With this PR the ugly _ can be avoided as follows:

• By setting the configuration option useContextualClassNames to true the classes com.example.TheClassSomeProperty and com.example.TheClassAnotherPropertySomeProperty will be generated.
• By setting the configuration option useContextualSubPackages to true the classes com.example.theclass.SomePropertyand com.example.theclass.anotherproperty.SomePropertywill be generated.
• Of course, both configuration options can be set to true. However, this will lead to redundant information in class name and package name.

[q-src]

This PR is now ready for review / merge @joelittlejohn.

[q-src]

@joelittlejohn I've just rebased against master. Is anything else needed for merging?

[joelittlejohn]

@q-src I'll be honest, I'm not really that keen to merge this change. It introduces a handful of additional complexities into the class naming, and we already have a lot of complexity there. It makes any change or improvement to class naming even harder to action because of the ongoing requirement to support this feature.

This plugin can't support all possible variants of generating Java output. At some point, you have to accept that when you use this plugin you get output of a certain kind - we can't maintain a config option for every possible variant in naming that a user thinks up.

I won't say this change is not useful - but I'm not yet ready to take on this complexity and be responsible for maintaining it forever more. You've added some good integration test, but I can guarantee that there are already edge-cases in the interaction between this and other config options that will not have been considered and will be opened as bugs.

I'd like to give the class naming strategy used by this project an overhaul; something akin to the deterministic scheme proposed by @samskiter in #554. The change proposed here makes improvements like that a lot harder.

[q-src]

@joelittlejohn Thanks for your statement. I understand if you're not going to merge this PR and of course will accept this.

[samskiter]

Hey again @joelittlejohn , it's been a while since I contributed to this project, but nice to think about it again...

I seem to remember that #561 was (IMO) an important internal change that might help toward #554. I think it was being more representative of the JSON structure, but honestly struggling to remember a lot of what it did now! If you'd like to pick back over it with me, I'd be happy to look again :)