Implement abstract games more fully (5.0.0)

[alexhroom]

This is a follow-up issue to #1413, and was originally mentioned in the discussion there - essentially, the "finishing off" of the refactoring when we are willing to make breaking API changes.

Following from the new implementation of Games (via asymmetric games as a base), AsymmetricGame was written so that it can take games of any size. Thus implementing larger games in general is trivial and the Game class can become more abstract and simultaneously far simpler with the following changes:

• remove RPST, which doesn't make sense for non-Prisoner's Dilemma games. if we really want to keep the RPST method, make it throw a NotImplementedError if the game isn't 2x2 and symmetric.
• rename AsymmetricGame to just Game, and have it take parameters in the following way:
  • if given two matrices, use them as payoff matrices A and B
  • if given one, assume game is symmetric and take matrix B as the transpose of A.
  • optionally, we could add a setting rpst = Tuple([Score, Score, Score, Score]) for users who want to use Press and Dyson notation.
    remove self.scores, as the game matrices now keep track of payoff scores. As far as I can tell, this is now only used in a small handful of strategies anyway.
• if we wanted to go even more general; have A and B be either matrices or Callables - if a Callable, this would be a function that takes an action pair and returns a payoff, or if a matrix would wrap the matrices in a function wrapper to match. This would allow games which don't fit the matrix format (e.g. 2/3rds of the average game, as mentioned in New Games #1328)

This would provide a far more robust and general design for the Game class with little difficulty.