Fixes java schema class type booleans for composed schemas
When a composed schema is defined with a type constraint, our tooling is not detecting that constraint and setting the boolean type properties in the class instance correctly.

This PR adds code which fixes that issue.
instance.setTypeProperties(schema) now sets those properties for object, array, number, integer, anyType, null, and string
which are the non-format types

Updates:

• CodegenModel/CodegenResponse/CodegenParameter/CodegenProperty now all set isMap isArray etc booleans with clearer if/else logic. Before some of that property setting depended on order specific blocks like isMapSchema. That logic has now been included in blocks for type object schema handling and any type schema handling.
• isAnyTypeSchema method is now marked as a deprecated method. It can be removed in a later major 6.0.0 release ModelUtils.isAnyType should be used in its place
• setParameterBooleanFlagWithCodegenProperty method is now marked as a deprecated method. It can be removed in a later major 6.0.0 release. Devs should depend upon the type setting adjacent to the invocations of instance.setTypeProperties(schema). If they need specific handling, then they can override methods like we do in master branch with updateModelForObject and updatePropertyForAnyType etc.
• If a composed schema does not have type set, it now has the property isAnyType set to true in the java layer.
• updates how array parameters are created in the Java layer. Originally our code was passing in fromFormProperty(name, arrayItemsSchema). This PR updates our code to pass in fromFormProperty(name, arraySchema)

PR checklist

• Read the contribution guidelines.
• Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
• Run the following to build the project and update samples:

  ./mvnw clean package 
  ./bin/generate-samples.sh
  ./bin/utils/export_docs_generators.sh
  

  Commit all changed files.
  This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
  These must match the expectations made by your contribution.
  You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
  For Windows users, please run the script in Git BASH.
• File the PR against the correct branch: master (5.3.0), 6.0.x
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.