Unsoundness in C enum handling

[d-e-s-o]

The handling of all enums in our C API bindings is unsound. E.g.,

blazesym/src/c_api.rs

Lines 303 to 310 in 9fe143a

	match x.feature {
	blazesym_feature_name::LINE_NUMBER_INFO => {
	SymbolizerFeature::LineNumberInfo(unsafe { x.params.enable })
	}
	blazesym_feature_name::DEBUG_INFO_SYMBOLS => {
	SymbolizerFeature::DebugInfoSymbols(unsafe { x.params.enable })
	}
	}

C code could set any value, including those not representable by Rust. Discussed in many places (while also being common sense...), among others here: rust-lang/rust#36927

[danielocfb]

So...after thinking about these potential issues some more I believe we should just live with them. If a user provides invalid enum variants through the C API that's on them and a bug in their code. We do not make any claims about being able to handle arbitrary wrong data, similar to how we would not identify a "broken" pointer (other than a NULL pointer; e.g., one that has been freed or just points into arbitrary memory). I am not sure we want to expend the energy to handle those invalid enum variants more gracefully. I am open to revisiting this issue in the future, but for now I am going to close it.