Fix for the bug #7343
Fix for the issue #7342
Fix for the bug #7343

Corrected the bug by adding solutions returned from
each individual equation to the `sols` set. Previous
error was due to replacing the last solution in `sols`
by the new solution rather than appending it to the `sols`.
Fix for the issue #7342

Change the return type of `diop_solve()` to a tuple in the univariable
case. Also added the checks to ensure that only  `Add`, `Mul` or a
`Symbol` is processed in the `classify_diop()` function. Raised an
error in the other cases.
Replace `==` by `is`
Fixed merge conflicts.

Conflicts:
	sympy/solvers/diophantine.py
Use the shortened version of `isinstance`. Replaced
`isinstance(eq, Add) or isinstance(eq, Mull) or ....` by
`isinstance(eq, (Add, Mul, ...))

Replaced the search for `None` using a for loop by using
`in`.
Use iterators in `merge_solution` instead of using counter
variables to keep track of the next element to be taken out
from `params` and `solution`.
Changed the `diophantine()` function so that it now respects the assumptions
imposed on the symbols. Originally the issue was raised in a so question found
in

http://stackoverflow.com/questions/23301941/how-can-i-declare-natural-symbols-with-sympy

and reported as SymPy issue #7444 by Aaron.

A similar approach as in `solve` is carried out to check for the assumptions.
Each symbol's assumptions are tested against the value returned by the
`diop_solve()` for that variable using `check_assumptions()`.
Remove an unnecessary blank line
Replace `Integer=True` with `integer=True`
Remove unnecessary lines in test case
Add a new test case
Use the function `numbered_symbols` for generating parameters
used in `merge_solution`
Add support for `Eq` and `Poly` in diophantine module.

In [1]: from sympy.solvers.diophantine import *

In [2]: diophantine(Poly(x+y))
Out[2]: set([(t, -t)])

In [4]: diophantine(Eq(x,y))
Out[4]: set([(-t, -t)])
Remove unnecessary imports `Add`, `Mul`, `Pow` and `Poly`.
`Add`, `Pow` and `Mul` had been imported already.
Moved the check for the allowed input formats from `classify_diop()`
to `diophantine()`. This make sense because the verfication of allowed
input formats should be done prior to the classification of the equation.

In [1]: from sympy.solvers.diophantine import *
In [2]: f = symbols("f", cls=Function)

Previously,

In [3]: diophantine(f)
TypeError: unbound method as_expr() must be called with f instance as first arg$

Now,
In [3]: diophantine(f)
TypeError: Equation input format not supported

Also, a test was added in `test_diophantine.py` to check whether the
exceptions are raised when the expected input formats are not found.

Also `Pow` was added to the supported input formats since it is possible
to solve the `Pow` types by `diophantine()`. Eventhough the exponential
diophantine equations are not explicitly supported, simple powers which
can be represented by `Pow` can be solved by `diophantine()` as the input
expression is treated as a `Mul` of (base, exponent) pairs.

In [4]: diophantine(x**y)
Out[4]: set([(0, n₁)])

In [5]: diophantine((x-y)**z)
Out[5]: set([(-t, -t, n₁)])
Update the docstring of `diophantine()` describing the output format
Replace the check for the correct input type with more elegant code.
Remove redundant `raise` statement.