Split functionality of item/fluid/energy interfaces

[josephcsible]

Note: Everything I say here applies equally to items, fluids, and energy, but for simplicity, I'll talk only about items.

Our item interfaces currently perform two distinct functions:

1. Claiming the inventory that they're connected to as belonging to the network (like an External Storage from Refined Storage). Most of the time that interfaces are used, this is their purpose.
2. Exposing the entire inventory of the network as their own (like an Interface with no export items set from Refined Storage). This functionality is much more rarely used.

You really only ever want one of these to happen at a time, and weird things can happen when both affect the same block. For example, suppose you point a hopper into an item interface, with the intent that anything you throw into the hopper ends up in the network. This works, but the hopper's inventory also counts as part of the network, so if all of the attached chests fill up, items will end up staying in the hopper. Further, if you were to add a second hopper like this, items would continually bounce between them as they were pushed out of one, then into the network, which is just the other one.

Two ways we can resolve this:

1. Split the interfaces into two separate things, like Refined Storage does.
2. Add a setting to each interface, allowing you to choose "Attach", "Expose", or "Attach & Expose".

[rubensworks]

Yes, this should indeed be improved.

I think option 2 would be a clean solution. Perhaps we could do this by adding "Input" and "Output" toggles to the interface part settings, which directly correspond to the item (and fluid and energy) interface methods.

[emanb29]

Another motivating example: Storage subnetting. In Applied Energistics or Refined Storage, a common pattern is to construct a storage subnet: The subnet "Expose"s the storages it manages, while the supernet "Attaches" the exposed storage. The analog in Integrated Tunnels would be having 2 item interfaces facing each other.

Currently, of course, this just causes the counted number of items in the system to double indefinitely, as the item interfaces expose each other's items to each other.

One benefit of such an arrangement would be to count storage capacity of designated storage areas, without polluting the counts with the capacities of, eg, storage drawers (or deep storage units, etc. -- any kind of storage that stores a lot of one item)