MAP: Refactor support manipulation

[tturocy]

This is an overarching roadmap item covering how we provide interfaces for manipulating "supports" (subsets of strategies or actions on a game). Comments on this issue are the best place to express any views you might have on this topic broadly.

Similar in spirit to #340, we want to standardise the way we present methods that manipulate games. However, the way we handle transformations of supports has historically been quite different. The most common operation, elimination of dominated strategies, has always been a member function of the support, even though it is actually an algorithm. Gambit also offers some support-enumeration approaches - but these have always been tightly coupled with enumpoly.

We will repackage support transformations as algorithms, which can be thought of as transforming a game into another game, or set of games. In Gambit 17, there will no longer be a need for a concept of a support, as mappings between games will be able to be done directly. In Gambit 16.x, we will evolve the interface towards that idiom. Supports will likely remain in the C++ code throughout Gambit 16, but we can deprecate and remove them in Python in favour of having mappers between elements of different games.

• FEAT: Create algorithm interface to eliminate dominated strategies from a game #346
• FEAT: Remove 'strategic restriction' concept from pygambit #338
• MAINT: Clean up implementation of support enumeration #401
• Unbundle support enumeration algorithms from enumpoly and expose as algorithms in their own right
• Remove support classes from Python interface

[tturocy]

These objectives have all largely been accomplished; a few pending items will be written up as separate issues.