Investigate if we are handling motion borders consistently

[danielsf]

Looking at the MotionBorder class defined in ophys_etl/utils/motion_border.py, I discovered that it does not contain data about the motion border. It contains data about the maximum shift applied to the movie in any given direction. See, for instance

https://github.com/AllenInstitute/ophys_etl_pipelines/blob/main/src/ophys_etl/utils/motion_border.py#L10-L60

Assuming it passes code review, I am going to rename that class MaxFrameShift and add a MotionBorder class that actually does contain information about the motion border (the positive number of pixels to ignore on any given edge of the field of view). This should be a part of #456 (assuming it passes code review).

In the course of making that change, I became concerned that we may not be consistently defining motion borders in our codebase. See, for instance, this code

https://github.com/AllenInstitute/ophys_etl_pipelines/blob/main/src/ophys_etl/utils/roi_masks.py#L240-L266

The docstring defines the zeroth element of border as "the border width on the right" but the code uses border[0] to determine if an ROI is too far to the left. This arises from the "motion border versus maximum frame shift" ambiguity. If a frame is shifted to the left during motion correction, that will make pixels on the right untrustworthy (either because of padding or pixel wrapping).

I think we need to go through our codebase and disambiguate where we mean a motion border (a positive definite number of pixels to ignore at a given edge of the field of view) and where we mean the maximum shift applied to a frame in a given direction during motion correction.