See #1335 (review), too, but in general, what's the difference between the unsafe block for a const and the unsafe on an unsafe fn (which in the latest edition is meant to also be an unsafe block in the unsafe fn, too)? They seem exactly the same to me, and I think we should approach them the same. So a change like this (which I haven't looked through all of the details of yet) makes sense to me if it also applies to an unsafe fn. Note that there are often a bunch of unsafe fns that are fully safe and don't need the unsafe, and removing the unsafe for a const that doesn't need it and remove the unsafe for a fn that doesn't need it seem like the exact same problem.

The difference is that there is no unsafe block surrounding definitions of consts prior to #1335 (nor after the first commit of this PR, transpile: revert set consts unsafe). This change (transpile: in const contexts, use `unsafe` around unsafe initializers) is really about following the same logic for initializers as we already follow for default zero values, several lines below: prior to this commit, our translation here follows the TranslationContext's notion of whether we're in a const context for the default zero values but doesn't for initializers.

When we change the edition we target, it will make sense to use WithStmts::to_unsafe_pure_expr in more places and we won't need to dispatch on the constness of the context to decide between to_unsafe_pure_expr and into_value anymore. The precision that this PR adds w/r/t which generated expressions are unsafe will also be useful for the translation of function bodies at that point.

History is cleaned up now; this should be good to merge.