Need serialized form and serialVersionUID for user-facing superclasses

When a class does not have an explicit `serialVersionUID`, it should be considered an unstable value based on the exact version of the code. This is fine for transmission most of the time, but never acceptable for persistence where backwards compatibility matters.

There are two use cases that require explicit serialized form and `serialVersionUID` even just for transmission. They are required for user-facing superclasses such as DoFn, WindowFn, etc, to support the following:

- Encoding a pipeline with a JDK and decoding with a JDK that computes defaults differently.
- Encoding a pipeline against a version of the Beam SDK and decoding with a different version.

The first situation should be rare since there is a deterministic spec, but we have unfortunately seen it.

The second situation is very reasonable; a runner might want to run with additional security fixes in the SDK, etc. Given a correct semantic version for the SDK, the pipeline author and runner author may reasonably expect it to work.

So we should add explicit serialization to superclasses that are necessarily encoded as part of a user's pipeline.

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

No files, tests, or entry points are named. Start by locating the user-facing superclasses mentioned in the issue, including DoFn and WindowFn, and determine which are encoded in user pipelines. Done means the required superclasses have explicit serialized forms and serialVersionUID values supporting the stated cross-JDK and cross-SDK compatibility goals.

Written by the indexing model from the issue text.