StateSpecs.combiningValue interface is very awkward to use

Using StateSpecs.combiningValue with built in combiners is very verbose. For example, to keep a running sum of ints:

```

@StateId("count")
private final StateSpec>
countSpec =
StateSpecs.combiningValue(
Sum.ofIntegers().getAccumulatorCoder(pipeline.getCoderRegistry(),
VarIntCoder.of()), Sum.ofIntegers());

```

This involves getting a reference to the pipeline into the DoFn, guessing/finding the proper type parameters for Sum.ofIntegers(), and manually pulling the accumulator coder out.

For combiners like Sum.ofIntegers() that have a fixed accumulator, the combiningValue call should be able to deduce that. Additionally, it would be nice to remove the type of the accumulator from the StateSpec object, since the user only needs the input and output types in their code.

Imported from Jira [BEAM-1276](https://issues.apache.org/jira/browse/BEAM-1276). Original Jira may contain additional context.
Reported by: millsd@google.com.

Start by locating StateSpecs.combiningValue and the built-in Sum.ofIntegers() combiner in the Java SDK. Review how the current accumulator coder and StateSpec type parameters are supplied, then determine the API changes needed for fixed-accumulator combiners and input/output-only state types. Done means the verbose example can use the simplified interface without manually retrieving the accumulator coder.

Written by the indexing model from the issue text.