Change app model for storing handicap to better reflect the SGF properties HA and AB

[herzbube]

Currently handicap stones are stored in the GoGame property handicapPoints, which is an array of GoPoint objects. The property value therefore stores two pieces of SGF information at the same time:

• The number of elements in the array denote the handicap as a numeric value. This corresponds to the value of the SGF property HA.
• The vertices of the GoPoint objects in the array denote the actual intersections on which the handicap stones are placed. This corresponds to the value of the SGF property AB in the game info node.

The property can be seen as part of board position 0 (zero), i.e. the root node. At the same time, the root node can also store setup information in a GoNodeSetup object. It would thus be possible for GoNodeSetup to clear handicap stones (corresponding to the effect of the SGF property AE), or replace them with white setup stones (corresponding to the effect of the SGF property AW). If this were allowed, saving the data to an SGF file and then reloading that SGF file would lose information.

Saving the data to an SGF file would result in the following content in the game info node:

• HA property with the correct numerical handicap value (taken from the GoGame property handicapPoints).
• AB property with less black stones than the HA property indicates (merge of the vertices indicated by the GoGame property handicapPoints and the setup information in GoNodeSetup).

Reloading the SGF file would result in the GoGame property handicapPoints to have a different value than at the time when the SGF file was saved.

To avoid this data loss, the app currently has to take special measures when the user is interactively setting up the board while at board position 0, and is removing a handicap stone, or replacing it with a white setup stone:

• The user is warned that doing so will result in the handicap stone being permanently removed.
• If the user confirms, the GoPoint object is permanently removed from the GoGame property handicapPoints.

In addition to this, the following coding items exists:

• Some of the methods of the GoGame class contain validation to guard against programmatical errors that might occur for interactions other than board setup.
• LoadGameCommand contains validation code that refuses to load an SGF file if it contains a game info node with an AB property that has less points than the number indicated by the HA property.
• GoGame has a property zobristHashAfterHandicap that needs to be specially maintained.

The special measures during interactive board setup, as well as the coding items in the above list, could be removed if the app's data model for storing handicap would be changed to be the same as SGF. In other words:

• GoGame has a property handicap that stores an integer value. This corresponds to the value of the SGF property HA.
• The GoNodeSetup property blackSetupStones of the GoNodeSetup object in the root node stores the GoPoint objects that denote the actual intersections. This corresponds to the value of the SGF property AB in the game info node.

Once these two changes to the data model are made, the following code modifications can be performed (list is probably not complete):

• The coding items listed above can be removed.
• When the user discards all setup information, the app should restore the default handicap stones according to the number stored in the GoGame property handicap.
• Drawing code that marks up handicap stones when viewing board position 0 needs to be adapted.
• Documentation of the GoGame method changeSetupPoint needs to be updated.

[herzbube]

Closing this because of "Won't fix" decision.

Rationale: The gap allowed by the SGF data model (handicap < number of black setup stones) is deemed to be not acceptable at this moment.