A lot of OpenVDB operations leave the precision of their arithmetic either implicit or to the ValueType of the given OpenVDB Tree. In both cases we end up with a bunch of warnings with more modern compilers (-Wconversion) about these expressions which mix with the return value types of other methods. This is also fairly inefficient. This ticket is to decide what (floating point) precision these operations should run at and standardise it across the code base. 

Reverting the following commit will list a large number of cases where the default OpenVDB build promotes these warnings:

https://github.com/AcademySoftwareFoundation/openvdb/pull/379/commits/91c11f4f959fc103992b1e9032578fc76703a086

This was originally attempted as part of a GCC 6.4.0 cleanup:

https://github.com/AcademySoftwareFoundation/openvdb/pull/379

But unveiled issues in regards to:

1) What precision should these calculations actually be done in. i.e. for FP precision, should all our calculations be done at double precision or left to the ValueType of the tree. We need to run some tests here in regards to performance and memory.

2) the math::zeroVal idiom. This allows for custom types to be used as grid types, so long as they implement math::zeroVal<Type> along with the required arithmetic operators. Obviously doing everything at double precision will break this workflow where explicit casts to double from ValueType may not be supported. We should decide where it makes sense to support custom types (e.g. does it make sense in interpolation/gradient ops?), supporting both where necessary and adding appropriate unit tests.