The parser_util method floatify_input forces bad data to be 0.0 but that could be misconstrued

[asgibson]

The method floatify_input is designed to take a value and force it to be a float. When unable to convert to a float, a default value of 0.0 is returned. While this makes sense because the method's requirement is to return values as floats, that may complicate telemetry understanding. A simple example would be telemetry that is garbled, or otherwise not seen as a floatable value and forced to 0.0 but is interpreted by a later construct as valid data. Perhaps in this instance, 0.0 is seen as good but the garbled value should have been a non zero value which was indicating something bad.

The frame and the low_level_data (VehicleRep's curr_data) allow for one non float value, '-'. This is meant of an indication of no value received and they are both initialized as a list of dashes. The method could return the dash instead of 0.0. Although we could also use NaN #154.

One final note: the test, FEASIBILITY, requires values to be floats and would need updated to accommodate missing values.

What should floatify_input do?