Proximity Search - Remove dependency and/or provide alternative on filter for other views handles

Subissue of #1469956: [Meta] - Improve Views-powered Geofield proximity searches

Currently, all the geofield_proximity related handlers are set up to rely on input from the views filter as their primary data source. I think this presents a couple of problems.

• UX: It wasn't immediately clear to me how to set up a view to display the distance from any certain location. I ended up looking at the code to figure out what was going on.
• Unnecessarily limiting: With the current state of the module, if I wanted to display a table listing the distance of every node from Chicago, I would have to add a filter that doesn't actually filter anything (i.e., > 0 or < diameter of Earth). That seems silly to me.

Based on discussions on our meta-issue (especially here), I suspect this was done to help prevent people from calculating the same point multiple times in the same sql sequence. I definitely think that's a great optimization to make, but I think it ends up making a weird "gotcha" in the administration of the module.

I'm not sure if this is the best way to deal with this, but I propose we offer an either/or. With all of the non-filter handles, we should allow the user to either select an origin point manually (i.e. textfield), or allow them to pull from a proximity filter. Ideally, it would be nice to pull from any proximity-related handler already on the view, but I can imagine that might be a little bit more difficult to code, especially considering relationships.