interaction.rs uses `&str` instead of `BnStrCompatible`

[ElykDeer]

This is in conflict with every other API, and would allow the APIs to be more generic/flexible.

[rssor]

For what it's worth, BnStrCompatible should be used less, not more. For a lot of the API that takes string-ish things, or things meant to be displayed, we should move towards only accepting &str. I originally used the trait to try to be more efficient when I had the data already in something null-terminated (CString, or a core-owned BnString), but too many of the places where we use BnStrCompatible simply aren't a scenario where it's likely to be used with anything except a static string.

So for things like registering commands, architectures, platforms, or other things where names are supplied: &str is probably the right move. The docs are much cleaner without the generic trait.

EDIT: To clarify, the trait should still be used inside function bodies to go from &str to something we can pass into the core, but its use as a trait bound in functions should be reduced moving forward.

[emesare]

We went ahead and moved forward with the &str params, most API's now will have that as the concrete type param.