Simplify specifying coders on PCollectionTuple

Currently when using a multi-output ParDo, the user usually has to do one of the following:

1) Use anonymous class: new TupleTag() {} - in order to reify the Foo type and make coder inference work. In this case, a frequent problem is that the anonymous class captures a large enclosing class, and either doesn't serialize at all, or at least serializes to something bulky.
2) Explicitly do tuple.get(myTag).setCoder(...)

Both of these are suboptimal.

Could we have e.g. a constructor for TupleTag that explicitly takes a TypeDescriptor? Or even a Coder? Or a family of factory methods for TupleTagList that take these? E.g.:
in.apply(ParDo.of(...).withOutputTags(mainTag, TupleTagList.of(side1, FooCoder.of()).and(side2, BarCoder.of()));

I would suggest both: TupleTag constructor should optionally take a TypeDescriptor; and TupleTagList.of() and .and() should optionally take a Coder.

Imported from Jira [BEAM-2536](https://issues.apache.org/jira/browse/BEAM-2536). Original Jira may contain additional context.
Reported by: jkff.

Start by locating the Java definitions and existing construction paths for TupleTag, TupleTagList, and PCollectionTuple, then trace how multi-output ParDo infers coders. Compare the proposed TypeDescriptor constructor with Coder-based TupleTagList.of() and and() factories; done means the API design is agreed and supports specifying output coders without anonymous classes.

Written by the indexing model from the issue text.