Crosshair Rework

There's a branch in the git repo home/cparker/crosshair_rework that is the first cut at doing some of these things. This branch wasn't particularly well planned out and is a hack. It was useful for sorting out how the crosshair works, how snapping works, and where all of the code is, but it's not ready for prime time.

Should snapping get its own blueprint?

Functions served by the crosshair:
* in the GUIs, indicate where the next click should take effect
** snapping is an important part of this. Often this is to grid points, but it can also be to pins or pads, the end points of other traces. Snapping could also be useful in scripts, so, it shouldn't be exclusively a function of the crosshair.
** the limits of the crosshair change when certain things happen in order to ensure consistency. For example, when a part is being moved, the limits of the crosshair are set so that part cannot be placed outside of the workspace (the "board").
* in the batch HID, remember the location of the last action. For example, scripts might execute a relative move of the crosshair in order to execute an action at a location relative to the previous action.
** If pcb had a better scripting language, then this might not need to be the case. Presently, there are no variables, conditionals, etc. in pcb scripting. Since changing this is a major thing, for the moment, the crosshair needs to retain this function.

Some goals for the revising the crosshair code include:
* define an interface for interacting with the crosshair
** a direct interface that code can use to manipulate it
** an action based interface that can be scripted, which could also allow gui hid tests to be scripted
* make the code modular
** This allows HIDs that want to use the crosshair to do so while others don't have to
** This allows plugins to replace the crosshair, or part of the crosshair functionality
* enhance the crosshair's ability to specify locations
** additional snapping targets
** horizontal, vertical, diagonal movement restrictions
* extract the snapping code to its own class
** The crosshair might not be the only thing that could benefit from snapping. For example, I remember something Peter C was saying about contours that didn't close exactly due to rounding errors
** it could allow the snapping functionality to be replaced or augmented by plugins
** it could allow crosshair plugins to also make use of the snapping functionality.
* Let the crosshair draw itself

Lessons from the first implementation:
** "Priority" **
This field was intended to be used to order the snaps in a particular way. It would allow snaps to be inserted into the list before or after other snaps. I'm not sure that this is really necessary. Instead of the SnapList structure that was implemented, it might be better to use a regular GList, since this is a more standard structure.

The priority could have been used perhaps to compute some sort of "weight" when choosing between multiple objects to snap to. So, you would create a list of all possible objects and their distances from the click, then say, multiply by the priority and see which gets the highest score.

Crosshair Actions:
We need a set of crosshair actions that can allow other parts of the program, or scripts, to interact with the crosshair. Some candidate actions:
* move crosshair
* pick up object
* put down object

Work items:
Collect crosshair code into crosshair.[c,h]: TODO
Extract and modularize the snapping code: TODO