[commit after #7859] literal keyword added to evalf and used throughout codebase

- [ ] decide whether the literal should attempt evaluation if the object is not a number; when numerical evaluation was used by is_positive then the _eval_is_zero routines didn't get used on unevaluated Sum and Product because the evaluation was able to show that the expressions *were* zero.

fixes #7642

`is_number` tells whether an expression is an abstract number, e.g. f(1) is a number in the sense that if you give an arbitrary function an argument of 1 you will get out some sort of number

Often, `is_number` is used to find out if something can be evaluated or not. This is not good and is the cause of problems like

```
>>> ask(Q.positive(f(1)))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "sympy\assumptions\ask.py", line 139, in ask
    res = key(expr)._eval_ask(assumptions)
  File "sympy\assumptions\assume.py", line 107, in _eval_ask
    return self.func.eval(self.arg, assumptions)
  File "sympy\assumptions\assume.py", line 177, in eval
    res = eval(expr, assumptions)
  File "sympy\assumptions\handlers\order.py", line 220, in Basic
    return AskPositiveHandler._number(expr, assumptions)
  File "sympy\assumptions\handlers\order.py", line 210, in _number
    if i._prec != 1:
AttributeError: 'im' object has no attribute '_prec'
```

To address this need, a new keyword was added to evalf called `literal` which will help answer whether a given expression can be evalf'ed with precision to a number or not. `is_comparable` only answers this for real numbers whereas the assumptions system mostly needs to know if foo can be evaluated to a complex number with imaginary part.