refactor: Use regular functions rather than FromStr impls

[Hocuri]

Implementing FromStr and then calling parse() creates an
indirection, which is hard to follow for people who are not familiar
with Rust. @r10s recently voiced this problem when we were pair-programming, and I agree.

We can decide what exactly to call the new function.

I didn't remove all FromStr implementations yet; FromStr for Fingerprint, FromStr for Params, FromStr for MozConfigTag and FromStr for EphemeralTimer are still left.

[link2xt]

Note about not using parse() can go into https://github.com/chatmail/core/blob/main/STYLE.md
And maybe similar for .into() and .try_into(), better use Type::from and Type::try_from and not implement such traits internally. In simple cases like converting vectors to slices and i64 to u64 with failing if it does not convert it seems ok to use existing .into() and .try_into() implementations, but we can also decide to always use e.g. u64::try_from(rowid)? instead of .try_into().

I looked at try_into() usage, and this is particularly difficult to read:

core/src/configure.rs

Lines 522 to 524 in 287d730

	let Ok(security) = params.socket.try_into() else {
	return None;
	};

The code actually called is here:

core/src/transport.rs

Lines 53 to 64 in 287d730

	impl TryFrom<Socket> for ConnectionSecurity {
	type Error = anyhow::Error;
	fn try_from(socket: Socket) -> Result<Self> {
	match socket {
	Socket::Automatic => Err(format_err!("Socket security is not configured")),
	Socket::Ssl => Ok(Self::Tls),
	Socket::Starttls => Ok(Self::Starttls),
	Socket::Plain => Ok(Self::Plain),
	}
	}
	}

Implementing FromStr and directly using from_str is somewhat fine, but then we can as well implement it not as a trait and call it new().

[r10s]

thanks a lot for that ❤️