Bounded and unbounded are not antonyms

## Motivation
It is currently possible to create a meaningless set of assumptions (fixes #8075):

neither
```
    Dummy(zero=True, finite=False) nor
    Dummy(zero=True, infinite=True)
```
raise an error.

### results

```
>>> S(0).is_finite
True
>>> S(0).is_infinite
False
>>> S(1).is_finite
True
>>> oo.is_infinite
True
>>> (1 + I*oo).is_infinite
True

also

>>> Dummy(integer=1).is_finite
True <--formerly None
>>> oo.is_rational
False <--formerly None
```

## major changes
- nonzero, finite and infinite are all complex
- nan has all attributes except `is_number` and `commutative` as False
- integers are now finite (hence oo.is_odd and other such integer properties are False)
- 16 of 17 issues in #8043 are addressed
- 2 XFAILed tests are now working
- about 7 tests with wrong results were corrected
- fixes #8081
- fixes #8088 

## todo

- [x] clean up S.in_Q discussion
- [x] **should `_eval_is_` routines ever have `self._eval_is_` calls in them or does this circumvent the action of the assumptions machinery?**  I don't think this is a problem. `_ask` will, when trying to determine foo, call all the foo prerequisites after figuring out what those are. When you use `self._eval_is` calls you are taking manual control of those prerequisites. On the other hand, perhaps this interrupts the prerequisite ordering by trying to answer a fact that may not be in the prerequistes (see #8088) and that may be a good reason *not* to use `self.is`. Anyway, changes made also fix #8088.

## review suggestion
Looking at the total diff is daunting. The commits are pretty self-contained, however, without changes in routines happening in different commits. So if they are looked at one at a time I think this is doable. I have also separated commits where routines are simply being shuffled (1 commit) or names are being changed (2 commits).

> 1) real & !rational does not make irrational true; irrational makes real and !rational. Proof:

Yes, but only in your branch.  That's wrong (c.f. standard definitions).