Clean up connectivity API and add tests

[ntolley]

This was raised by @rythorpe in #276. The current connectivity API allows for duplicates of the same connection when specified through net.add_connection(). Currently connectivity information is stored under net.connectivity as a list, so implementing this check would require looping through the entire list every time a new connection as added which seems like an unnecessary overhead. I think this check will require converting net.connectivity to easily lookup/index existing connections between cells.

Another much needed check is ensuring valid cell-cell connections are specified. Currently invalid connection types (inhibitory synapses on L2 proximal/distal dendrites for example) only throw an error when the network is built. Ideally this will be caught in add_connection(). This should also come with clear documentation of what constitutes valid cell-cell connections.

[ntolley]

Renaming this issue to reflect problems that came up during #318

Here are the major points that should be addressed in a followup PR

• [x] More verbose warnings for invalid connections (as described above)
• [x] Merge the functions used for drives and cell-cell connections. This is partially done as everything is funneled through net.add_connection, but the next step is allowing the drives to target specific gids in a similar API #369
• [ ] Make _Connectivity a proper class wit public and private attributes
• [x] Add .drop(probability, src_gids, target_gids) .plot
• [x] Function to search for specific connections in net.connectivity list: conns = pick_connecitivity(conns, src=‘L2_pyramidal')
• [x] Viz function that plots connections weights with color bar as plot_connectivity(net, conn)
• [x] Streamline code path for when exogenous drive connections are overwritten / destroyed and recreated (see https://github.com/jonescompneurolab/hnn-core/pull/446#discussion_r813112732 for context)

[ntolley]

@kenloi this is the issue I was describing earlier about verbose warnings. This would also be a good opportunity to learn about what is considered a "valid" connection in the canonical microcircuit.

[jasmainak]

what's left here @ntolley ?

[ntolley]

I recall from an older discussion that we moved away from making _Connectivity it's own class. Also #419 was the major goal for adding more verbose warnings so I think it's save to close this issue!