No error for no-ops in ungroup and friends

[hamogu]

Currently, ungroup and unsubtract throw a DataErr, if a dataset is not
grouped or not subtracted. Why is this necessary?
For purely interactive use if just one or two datasets, an Exception is one way
of providing feedback to the user and remind him "hey, you did not even group
this before, are you sure you know what you are doing?".
However, when working with more datasets, it gets annoying and it's even worse
when I have a long-running script. Why does the script fail, if all I'm doing is
to accidentally ungroup something that was ungrouped before.
Here is what I do: I play around interactively, group with or that and then I
want to ungroup or unsubtract everything. Currently, I have to go one by one,
with code like this:

for i in ui.list_data_ids():
        try:
            ui.ungroup(i)
        except sherpa.utils.err.DataErr:
            # It's already ungrouped
            pass

That's clunky, so I wonder: Why is it necessary to throw an Exception when a
dataset is already ungrouped or unsubtracted?
If I want to ungroup, why would it matter to me if data was previously grouped
or not? What matters is that it's ungrouped after.

This PR removes some of those (in my opinion) annoying exceptions.

Note that this needs a through review not just for the approach, but also for the implementation. I'm new to the Sherpa internals and the fact that no test needed to be changed to make it pass locally indicates that the exceptions are not covered by tests.
(If there is agreement to proceed with this, I'll add a test.)

[hamogu]

Note that the current practice is asymmetric: While ungrouping an already ungrouped spectrum raises an exception, grouping an already grouped spectrum (even when using the exact same grouping) is accepted.

[anetasie]

@hamogu Thanks, Yes, no-ops in ungroup would be good.
btw. when ungroup operates on grouped data it will group the data to reflect the new grouping. It should operate on original ungrouped data.

[hamogu]

OK, added tests.

[hamogu]

A related question (beyond the scope of this PR): Why is there a grouped flag for datatsets at all? Why not just use the grouping all the time and set it to use every bin initially? That would make the code a lot less complex by removing a lot of if grouped ... else ..., I guess there is a performance penalty, but is it severe enough to justify that added code complexity?

[hamogu]

I verified locally that the new added tests fail without this patch.

[dtnguyen2]

The file sherpa/astro/tests/test_astro_data.py is missing the year which the file was updated in the Copyright section.

[hamogu]

I added the new copyright year. Technically, in 2020 that copyright is by MIT and not SAO, but I'm happy to pass it on to SAO ;-)

[hamogu]

@dtnguyen2 I addressed your comments a while ago. Please have a look again when you find time, it would be nice to get some stuff merged.

[wmclaugh]

I suspect this is intended to catch False or None- if so, pep-8 suggests using if data.grouped is not True:

[hamogu]

This is taken from the old code (line 7265, seen in diff above if you expand it a little). I'm not aware of cases where data.grouped would be none.