[ML] Add ML result classes to protocol library

[droberts195]

This commit adds the ML results classes to the X-Pack protocol
library used by the high level REST client.

(Other commits will add the config classes and stats classes.)

These classes:

• Are publically immutable
• Are privately mutable - this is perhaps not as nice as the
  config classes, but to do otherwise would require adding
  builders and the corresponding server-side classes that the
  old transport client used don't have builders
• Have little/no validation of field values beyond null checks
• Are convertible to and from X-Content, but NOT wire transportable
• Have lenient parsers to maximize compatibility across versions
• Have the same class names and getter names as the corresponding
  classes in X-Pack core to ease migration for transport client
  users
• Don't reproduce all the methods that do calculations or
  transformations that the the corresponding classes in X-Pack core
  have

[elasticmachine]

Pinging @elastic/ml-core

[droberts195]

This is labelled >non-issue as it's useless on its own. It's groundwork for future changes that will make ML endpoints available in the HLRC.

[benwtrent]

The build out of the pojos seem ok to me.

My only nit is with inconsistency with overriding equals. Some use instanceof without making the class final others getClass(). On the surface, the decisions seem arbitrary and look like artifacts from copying/pasting from old code written by many people over time.

[elasticmachine]

Pinging @elastic/es-core-infra