Allow demangling improperly `c++filt`ed symbols (maybe through an opt-in `--feature`?)

[danielhenrymantilla]

Consider __ZN4core5slice29_$LT$impl$u20$$u5b$T$u5d$$GT$16sort_unstable_by28_$u7b$$u7b$closure$u7d$$u7d$17hcf92dcf9c48f99dbE.

rustc-demangle properly unmangles this as: _core::slice::<impl [T]>::sort_unstable_by::{{closure}}.

But if some intermediary debugging tool were to assume the more common C++ mangling scheme, and attempt to demangle it as such (à la c++filt), we then end up with: core::slice::_$LT$impl$u20$$u5b$T$u5d$$GT$::sort_unstable_by::_$u7b$$u7b$closure$u7d$$u7d$::hcf92dcf9c48f99db.

And by then rustc-demangle (silently) does not recognize mangled input, and decides to just output it back, as-is.

While we could submit this kind of issue to rustc-demangle, it could legitimately be deemed out of scope for it.

However, for a CLI convenience tool such as rustfilt, it could be more legitimate to expect it to be more flexible w.r.t. the input it needs to handle.

If adding a "C++ mangler" involves too many deps, that functionality of rustfilt could be --feature-gated, for instance 🙂