Elevation void handling

**Describe the bug**
Elevation voids can be present in different elevation providers that GraphHopper supports like SRTM. Currently, ElevationProvider returns NaN as the elevation where a void is present, and `Helper.eleToInt` converts that NaN to 0 for storage so all voids appear as having an elevation of 0 which could lead to large reported elevation gains/losses.

**To Reproduce**

Steps to reproduce the behavior. For examples:

1. checkout recent and stable version of GraphHopper
2. Import north-america_us_pennsylvania.pbf using foot/fastest and SRTM elevation provider and start local UI `./graphhopper.sh -a web -i north-america_us_pennsylvania.pbf`
3. Open http://localhost:8989/maps/?point=40.69086%2C-77.459169&point=40.686342%2C-77.464393&locale=en&vehicle=foot&weighting=fastest&elevation=true&turn_costs=false&use_miles=false&layer=TF%20Outdoors
4. You can see a void that falls back to 0 in the middle of the route.

**Expected behavior**
It would be better if we excluded these artificial gains/losses from ascent/descent calculations and elevation-influenced routing algorithms, and for the elevation profiles, either:
- interpolate elevation across the void to just make it look like a consistent grade between data that we do have
- omit elevation from points in the void so it is clear that there is no data and elevation isn't actually 0m