Reporting connections between regions

Master issue to track progress towards implementing the API features needed for a user to answer queries about direct connections between regions. These queries are solvable just by inspecting the appropriate metadata objects / network objects, and should not require any actual network analysis algorithms to be done.

The first two query is:

- Does region A directly connect _to_ region B?

The user should be able to specify whether to do this lookup via the "reported" connections - IE those that are present in the network itself; and "all" connection reports - IE to lookup all possible matches in the `edge_info` table.

The next queries are:

- What are the bidirectional connections of region A? [As per Zulip](https://brainglobe.zulipchat.com/#narrow/channel/581506-neurome-browser/topic/Quering.20for.20Bidirectional.20Connections.20.26.20Filters/near/601118757), interpret this as "Which regions B have a bidirectional connection to A?", which is important when considering the filter below.
- What first-order connections do regions A and B have in common?

In which the user should be able to specify whether the connections to be considered in common are with A and B as the input nodes targeting the same common node, output nodes targeted from the same common node, or either ("both").

Another more general query that we should be able to ask is:

- What are the direct (first-order) connections of region A?

Where the user can specify _both_ whether to do this by the "reported" or "all" connections, as well as by "input"/"output"/"both", as described above.

A final, specialist query that is wanted is the following:

- Does region A connect to it's contralateral counterpart?

However we may elect to implement this elsewhere, since this is just a special case of the above lookups.

## Plan of Action

- Write `direct_connections` method.
- This method should take a node index as an input, as well as suitable options for the two filters that we may want to apply.
- It should return a suitable identification of the edges that are discovered. Note that looking up via the network and via the `edge_info` may produce different outputs in different formats, and the latter may return multiple connection reports for the same edge. The method will need to be able to handle this appropriately.
- Write specialised methods for the remaining queries, which can all make use of the general method we wrote above.
- What first-order connections do regions A and B have in common?
- Does region A directly connect _to_ region B?
- What are the bidirectional connections of region A?

Start by locating the existing network and metadata access points, including the edge_info table, and identify the entry points for region and edge lookups. Read the planned direct_connections method requirements first, then map how its reported/all and input/output/both options should support the specialised queries. Done means the general lookup and the listed specialised methods are implemented with suitable edge identification.

Written by the indexing model from the issue text.