Fix GroverOptimizer's rotation_count

[t-imamichi]

Summary

Fixes #129

GroverOptimizer's rotation_count is set in a wrong way.
It is originally rotation_count = int(np.ceil(algorithm_globals.random.uniform(0, m - 1))), but it is always 1 if m=1.
It should be either 0 or 1. So, I replace it with algorithm_globals.random.integers(0, m).

The order of result.get_counts(qc) has an issue. It is sorted by probability, but some bitstrings may have the same probabilities and it results in a probabilistic behavior of unit tests on different environment (mac and linux).
This PR sorts the counts by bitstring order if qasm_simulator is used. So, the resulting iterator has the same order in any environment.
If statevector_simulator is used, it omits the sort because the results are generated in a sorted order.

Details and comments

[a-matsuo]

LGTM! The code rotation_count = int(np.ceil(algorithm_globals.random.uniform(0, m - 1))) was not working as expected. We needed random integers including 0. However the code did not return 0 since it has ceil.

[t-imamichi]

A question is still left. A function is_good_state in grover_optimizer is used for making Grover object. But, I found that is_good_state is never used. Even if I put assert False in it, the unit tests pass. This is the reason why is_good_state has a wrong signature, which I fixed in this PR, but it did not raise an error in the past.

As a conclusion, we need overhaul GroverOptimizer.

[woodsp-ibm]

A question is still left. A function is_good_state in grover_optimizer is used for making Grover object. But, I found that is_good_state is never used. Even if I put assert False in it, the unit tests pass. This is the reason why is_good_state has a wrong signature, which I fixed in this PR, but it did not raise an error in the past.

Looking at the coverage output from CI here, is_good_state code is still not covered by unit tests - it looks like its still not called at all despite being passed to Grover.

[t-imamichi]

I see. We should add a unit test of is_good_state in the future.

[woodsp-ibm]

I see. We should add a unit test of is_good_state in the future.

I would have imagined that is_good_state should have been called by Grover during its normal operation. As such I am unsure why coverage shows that its not called - and your comment above indicated its not called since even with parameters mismatching on the signature it should get called, but may go wrong/exception. Does this need further investigation?

[t-imamichi]

Yes, we need further investigation about is_good_state in a separate issue. Since it does not seem to affect the existing unit tests, I think we can merge this PR.