Proposal: Add UserType to process method of TypeProcessor for more flexible code generation

I'm writing a TypeProcessor that adds a method in generated code for a thrift union type.
Since the processor only gets the generated class as input parameter, it's rather hard to figure out if the generated Thrifty code reflects a union in thrift.

I came up with the following which seems rather fragile to me:

boolean isUnion = type.typeSpecs.stream()
        .filter(e -> "Builder".equals(e.name))
        .findFirst()
        .flatMap(t -> t.methodSpecs.stream().filter(m -> "build".equals(m.name)).findFirst())
        .map(m -> m.code.toString().contains("Invalid union;"))
        .orElse(false);

Would it be a good idea to add the userType as a second argument in the process method? It would make code generation in general a lot easier since generated code can be based upon the thrift schema AST instead of the generated code.

I can draft a PR if this seems a good idea. Changing the method will break the TypeProcessor api.

Start by locating the TypeProcessor process method and its generated-class input, then trace how the thrift union schema and userType are represented. The proposal is complete when processors can access the schema AST through the API rather than inferring union status from generated code, with the breaking API change addressed.