PointFeature (FPFH) does not honor ITK filter/pipeline semantics

[hjmjohnson]

The itk::PointFeature filter (FPFH descriptors), ingested into Modules/Registration/FPFH, does not follow ITK's filter/pipeline conventions. It works only when its compute method is called manually, which is surprising for a class deriving from MeshToMeshFilter.

This is filed as a follow-up to the FPFH ingest so the ingest itself stays a faithful import; the redesign should be evaluated separately.

Specifics

• GenerateData() is effectively a no-op: it checks the input point count and returns without computing anything or setting the output. Calling Update() therefore produces no FPFH output.
• The algorithm parameters radius and neighbors are not pipeline parameters (no Set/Get macros, not part of the Modified()/GetMTime() machinery). They are passed only as arguments to the public ComputeFPFHFeature(input, normals, radius, neighbors) method.
• The result is exposed via GetFpfhFeature(), which returns null until ComputeFPFHFeature() has been called manually.
• Input normals are supplied as a second PointSet whose point positions are the normal vectors, rather than via point data.

Suggested direction (to be evaluated)

• Add itkSetMacro/itkGetMacro for Radius and NeighborCount (or itkSetGetDecoratedInput for the normals point set).
• Move the body of ComputeFPFHFeature()/ComputeSPFHFeature() into GenerateData() and emit the descriptors as the filter output (or a decorated output), so Update() works.
• Consider enforcing 3-D input (static_assert(InputDimension == 3) or a concept check), since ComputePairFeatures hardcodes three components.
• Validate that input_normals has at least as many points as input before indexing.