Reorganize arrows directory structure by functionality

[predicative]

The current structure of the arrows directory is more or less that there's one subdirectory per external dependency, under which all the arrows for the dependency are placed. For instance, there are ocv (OpenCV), vxl, and ffmpeg directories. However, it would be nice if the arrows directory was restructured to be organized by functionality. For instance, all tracking-related code would go under a tracking folder. Breaking things out by dependency could be done within the functionality folders.

Clipped from an email from @mattdawkins regarding tracking in particular:

We [Juda, Matt B, I] talked briefly about this on Tuesday and decided we would likely pursue the tracking folder arrow with core, opencv, pytorch, etc... under the hood (so two level directory structure), just where each of those folders could also optionally have enable flags for turning on different tracker sub components, and this could always be further broken up down the line if they get too large down the line and the python install macros are improved to prevent max folder depth issues on windows we are currently seeing with the sprokit py file installs.

... We didn't discuss what those enable flags would look like but I'd prefer something as short as possible and not compounding across both dependencies and subcategory, e.g:

KWIVER_ENABLE_TRACKING KWIVER_ENABLE_PYTORCH KWIVER_ENABLE_TRACKING_INIT (Advanced, turned on when tracking on) KWIVER_ENABLE_TRACKING_LINKING (Advanced, ...)

not

KWIVER_ENABLE_TRACKING_PYTORCH or KWIVER_ENABLE_TRACKING_PYTORCH_INIT

which would just get too long IMO

[mleotta]

I agree that we need to start organizing arrows more by functionality. However, there is also a need for some arrows to be tied more directly to the external dependency they bring in. I think there is still a need for opencv and vxl arrows to contain low-level capabilities that are broadly useful across many applications, like conversion between image representations. Arrows more focused on a functional area can then directly link to these build-block arrows.

In general, it is best to keep any one arrow limited in it's dependencies as possible. This way, if someone is blocked from using some dependency for some reason (e.g. license, file size, lack of GPU, etc) they can still use the other capabilities that do not require that dependency. It's also less desirable to have arrows that may or may not contain some capabilities depending on how your build was configured. It's much easier to understand the system if plugin A will always give you features X, Y and Z.

I'm not sure I see a strong need to have separate arrows for separate stages of tracking (through certainly separate algorithms and processes within an arrow makes sense). The main reason to separate track linking for track init at the arrow level is if you think there are applications to be built on KWIVER that would only care about one stage or the other and would want to reduce binary sizes by only including the piece that they need. I would think that if you are doing tracking you probably want access to both initialization and linking most of the time. If we go too fine grained on the modularization we will run into other issue like increased start-up time as we have to load many more plugins. Note that organization of code and directory structure can still logically separate capabilities within an arrow.

The actual CMake configuration options for KWIVER could be updated somewhat orthogonally from the break down of arrows. We do not need to stick with this one-to-one mapping between KWIVER_ENABLE_* options and arrows. In fact it might make sense to have a combination of KWIVER_USE_<dependency> options and KWIVER_ENABLE_<functionality> options. Some ENABLE options would then enable multiple arrows that support the functionality, and some arrows (like a pytorch tracking arrow) would require enabling both a USE and ENABLE option (KWIVER_USE_PYTORCH and KWIVER_ENABLE_TRACKING). Also, different ENABLE options could activate the same arrow if both functional groups need common functionality.