C-CTOR needs more nuance

[brson]

It mostly covers empty ctors.

It also hints via example that there exist 'conversion constructors' of the form from_foo, without describing them, but:

• What should I do about non-empty ctors?
• What should I do about 'secondary' constructors that are not 'conversion constructors', that e.g. take multiple arguments?
• When should I implement from_foo vs. From<Foo>?

[cbreeden]

Concerning the from_foo vs From<Foo>, I did a quick survey of the standard library, and found the majority of the from_X methods were in one of two categories:

1. Unsafe functions. This includes Box::from_raw, Arc/Rc::from_raw, etc. In particular, collection and smart pointer types that can be constructed from raw pointers. This also includes unsafe conversions.
2. Data-type is insufficient for determining encoding. This is often used in cases where you just have a "collection of bits" that need to be encoded into a type:
   - {integer}::from_[be/le]
   - {integer}::from_str_radix - also see TryFrom note below, but this belongs here.
   - {float}::from_bits
   - str::from_utf8 - also see TryFrom note below, but this belongs here.

It's also worth noting the FromStr <-> .parse pairing, and while this may add semantics, it seems like it is more of a work around for not having TryFrom. In particular, these are scenarios where the source-target pair is sufficient for determining the transformation.

[dtolnay]

This was mostly covered by c7a5907. I added e17bacf to explain the differences between from_foo and From<Foo>.