Support arbitrary PDAL filters

[hobu]

It would be really convenient if API users could post just the "filters" part of a PDAL pipeline to the API. This would allow an API user to string together their own operations and have those operations happen near the data.

There will be at least 3 different ground filters available in the news PDAL, for example. GRiD's API doesn't need to create 3 different and distinct API calls for each. Giving API users the ability to construct and compose their own operations will mean the API can be simpler longer term.

There's of course some gotchas:

1. Some filters generate multiple outputs. Do we allow those?
2. Some filters take incoming data, like a filters.colorization taking a WCS URL. Do we allow those?
3. Many filters create new data fields and new data. They very well might not work for the given output format. It may be that we only want to expose results of these runs as Greyhound services

For example, it an API user might post the following:

[
    {
      "type":"filters.crop",
      "bounds":"([0,1000000],[0,1000000],[0,1000000])"
    },
     {
      "type":"filters.normal",
      "knn":8
    },
    {
      "type":"filters.poisson",
      "depth":"8",
      "point_weight":"4"
    }
]

[chambbj]

:+1:

FWIW, I think this could be a useful feature within PDAL as well. We can already workaround this by overriding reader/writer filenames in a all to pdal pipeline, but it seems a common enough use case to run pdal translate with an input and output filename and a filters-only pipeline specification.

[AlexMountain]

This has been added as an enhancement to v3. Custom PDAL filters can be passed to point cloud exports using the custom_filters parameter.