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

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.