Rework use of `internal` to allow defining of callabes that are not part of public API but implemented outside of original binary

[swernli]

If I mark a Q# callable as internal but also as body intrinsic it must be implemented in the same binary or in a binary that has been allowed via the InternalsVisibleTo attribute. If we want to allow implementations of Q# helper callabes to come from outside of this repo, we need a different way to expose those callables that is neither public nor internal. Perhaps an attribute on a non-internal declaration that marks it as not part of the API surface? Some other trick that makes use of specific patterns in the generated code?

See discussion for this issue in #367, as well as original context in #249.

[swernli]

The interface based design introduced when addressing #432 in the feature/decomp branch may be our best path forward to fixing this. Extending that design would allow for body intrinsic callables to be generated into concrete C# classes instead of abstract, and then expect an implementation that corresponds to a generated interface to be provided. This will allow for any external package to provide the implementation of the callable, and is conceptually a stepping stone toward the QIR designs. Whether we actually take that incremental step now just depends on how much more we want to invest in the C# generation vs wait to take advantage of the QIR for this purpose.

@bettinaheim for FYI.