Give IntegrationPlugin's per-type methods a kind

[jadamcrain]

Item 6 of #59.

Changes

• Point kinds. PointKind is now the one kind of point. InputKind[P], typed by its points, and a new OutputKind are its subsets, and every kind is an object in PointKind. InputKind's own objects are gone.
• Uninstalling. uninstall(reporter, kind) replaces the seven uninstall* methods. It's abstract. Two of the methods it replaces, for frozen counters and analog inputs, had defaults that threw, so a plugin now handles every kind or throws itself.
• Patterns. generatePattern(reporter, kind) replaces the three generate*Pattern methods.
• Operate checks. checkOperate(reporter, kind, index) and checkNotOperate(reporter, kind) replace the four check*Operate methods.
• Unchanged: the other optional actions keep their defaults that throw. DefaultIntegrationPlugin asks the same questions as before, except that uninstalling frozen counters and analog inputs now asks for "every ... point" like the other kinds. The procedures' steps are unchanged.

Downstream

stepfunc/dnp3's conformance plugin needs the matching change: it implements the four new methods, renames InputKind.X to PointKind.X, and drops supports.noClassAssignment from its configuration files. That change is ready on dnp3's dnp3c-3.1r1 branch, and I'll push it after this merges.

Checks

• mvn test passes.
• dnp3's plugin: I updated it locally and ran its 3.1r1 level 3 suite against a local build of this branch:
  • every section passes, apart from the outstation gaps its configuration already lists
  • the gap tests that uninstall points (8.16.1.2.4, 8.21.1, 8.21-8.13.2-4, 8.23.2.x.1) uninstall the right kind each time, then fail only on the known missing IIN2.1/IIN2.2 (dnp3 #478)