TryInto<T> support + Into<T> with scalars

[polarathene]

The crate docs mention scalar types are not supported and the reasoning appears to be clarified in the source?:

buildstructor/src/buildstructor/utils.rs

Lines 343 to 348 in ae0a5a4

	// Scalar types don't need to use into, they the compiler will convert.
	for scalar_type in SCALAR_TYPES {
	if ident == Some(format_ident!("{}", scalar_type)) {
	return false;
	}
	}

That's not the case though if you had a type that would convert to a scalar type via the Into trait? For example:

struct WrappedString(String);

impl From<WrappedString> for bool {
  fn from(s: WrappedString) -> Self {
    match s.0.as_str() {
       // Different string value mappings to `bool`
      "yes" => true,
      "no" => false,
      // Could alternatively panic, or if `TryFrom` could error:
       _ => false,
    }
  }
}

AFAIK, the convenience is to avoid calling .into() with the value passed to the parameters builder method? For the inverse (impl From<WrappedBool> for String), that is supported since the assumption for scalars doesn't apply now.

I found that a little odd, but I understand the intention to avoid it by default. Perhaps an annotation could opt-in, or similar with how you've got Option<T> supported, something similar could be done with param: Into<bool>?

---

Another example might be a enum that wraps scalar types. Although conversion to a scalar is likely fallible and there does not appear to be equivalent support for the TryInto trait (thus it needs to either be handled by the user before passing the value in, or more verbose constructor impl).

If creating a fallible builder, it seems support for TryInto might be beneficial in the same way? It might be a bit trickier with the error types, but if a crate like anyhow is in use it can be workaround via:

// Like `.into()`, except if it fails map the error to a common one for the returned `Result<T, E>`:
// https://docs.rs/anyhow/latest/anyhow/struct.Error.html#method.msg
// https://doc.rust-lang.org/std/result/enum.Result.html#method.map_err
parameter.try_into().map_err(anyhow::Error::msg)?

Making that implicitly handled similar to the Into support may require an annotation for the map_err() value/closure.

---

I'm not sure how much interest there would be for implicit TryInto<T> to match the Into<T> support. Opening this issue to collect 👍 and better document the caveats I ran into :)