REL-2057: ROI Exception

Root cause of this exception is that existing ROIs for GMOS observations can be invalidated by changing the detector (because of different CCD sizes). So far the editor was keeping users from adding invalid ROIs (overlapping, ranges, numbers) but since changing the detector can now invalidate an existing ROI after insertion (range, number of ROIs) it seems futile to try to keep users from entering invalid ROIs and then assume all entered ones must be valid. Also we have to live with the fact that - in case ROIs became invalid after they've been entered - we need to be able to deal with them for example during export/import cycles. This is btw. what originally triggered us to detect this problem (see stack trace).

In order to solve this issue I changed the code so that no validation is triggered anymore during import, i.e. we accept "invalid" ROIs. However it is important to bring invalid ROIs to the user's attention, so (after checking with Andy) I also added a phase2 check that will detect invalid ranges for ROIs (there were already checks in place for the number of ROIs and overlaps, therefore it seemed natural to add a test that detects range problems).

Not insisting on validating ROIs before they are entered had also the advantage that I could simplify some of the code and localize the validation of the ROIs a bit better and as a bonus add some more warnings in the ROI editor (they repeat the phase2 error checks, but it seemed to make sense to show them there, too). [It would of course still be possible to keep people from inserting ROIs that are invalid for the current settings, but it didn't seem to be worth the effort as long as there are checks that make it transparent to users that there is a problem.]

As always, there is of course more cleanup potential, but I thought I draw a line here and declare it done.