Alter `ScalarValue` APIs to be more clear when an operation isn't permitted

[Jefffrey]

Some of the APIs for ScalarValue are confusing in which operations are permitted. For example:

datafusion/datafusion/common/src/scalar/mod.rs

Lines 1446 to 1452 in 5419ff5

	/// Create a zero value in the given type.
	pub fn new_zero(datatype: &DataType) -> Result<ScalarValue> {
	Ok(match datatype {
	DataType::Boolean => ScalarValue::Boolean(Some(false)),
	DataType::Int8 => ScalarValue::Int8(Some(0)),
	DataType::Int16 => ScalarValue::Int16(Some(0)),
	DataType::Int32 => ScalarValue::Int32(Some(0)),

If the data type doesn't support the concept of a zero value, we return an error. Ideally callers would check for this error, but usually we just bubble any errors up with ?. Perhaps we should consider changing the return to be an Option so the caller can match on whether the given datatype has a zero value or not, instead of resorting to using Result to represent this?

Another example:

datafusion/datafusion/common/src/scalar/mod.rs

Lines 1798 to 1801 in 5419ff5

	pub fn new_ten(datatype: &DataType) -> Result<ScalarValue> {
	Ok(match datatype {
	DataType::Int8 => ScalarValue::Int8(Some(10)),
	DataType::Int16 => ScalarValue::Int16(Some(10)),

Here, for decimals we can't actually represent a value of ten if we have negative scale less than -1; so we return an internal error in that case, but that means callers need to either prevent calling this function with a negative scale decimal (that isn't -1) or match on the result. If we encode it as Result<Option<_>> instead, with the Result reserved for returning errors in case of unusual behaviour (e.g. invalid precision/scale combination), it can make it more clear that sometimes the value of ten just doesn't exist.

[shifluxxc]

take

[Jefffrey]

Another case to consider: when we call ScalarValue::new_ten() for DataType::Decimal(1, 0); this is technically invalid.