Create bus.asm call to expose native BusInteraction to the backend

[qwang98]

Currently just the bus.asm call is created. Next step will be editing bus.rs linker to do this call for backends that needs the native bus interaction.

A key quesiton remains whether we need to import the backend crate or create another linker mode in the linker crate in order to distinguish which cases to pass down the native bus interaction vs which cases to call bus_multi_linker.

A third solution is to make both bus_multi_linker and bus_native_linker call in bus.rs, and this will create both BusInteraction and PhantomBusInteraction for all backends, and some backends can just ignore the native BusInteraction, similar to what we've done for native lookup and permutation.

[qwang98]

After a chat with @Schaeff, I opted for the method to simply expose native BusInteraction together with PhantomBusInteraction. However, a few future questions/potential updates remain:

1. The current infrastructure won't allow for a "mid-linker" optimizer for bus send/receives. One example discussed is potentially turning send([a, b], selectorLHS); receive([c, 1], selectorRHS); to send([a], selectorLHS); receive([c], selectorRHS); selectorLHS * b = selectorRHS * 1. I think these should be mathematically equivalent, proved as: "during selectors, if a match c and b = 1, then [a, b] match [c, 1]" as well as "during selectors, if [a, b] match [c, 1], then a match c and b = 1". Because the statements hold for both ways, they are mathematically equivalent. However, we should be very sure that this is correct before rearranging the API to allow for such a "mid-linker" optimizer.
2. Because now witgen receives both PhantomBusInteraction and BusInteraction for the same bus interaction, I modified the witgen convert_identity code to simply ignore BusInteraction instances. However, if we choose instead to send EITHER PhantomBusInteraction OR BusInteraction in our final API, we would need to add back the convert_identity witgen code for BusInteraction.
3. I'm not sure what's our final plan with Stwo is regarding native LogUp. After discussion with @Schaeff, it sounds like we should still keep the majority of such constraints in PIL. With this PR, any backend will receive native BusInteraction but LogUp constraints and stage-1 columns are still built in PIL.

[qwang98]

Ready for review.