Split SOCBoard into Standard4p and Standard6p. Tidy up SOCBoard.

[generateui]

SOCBoard is a "God-class". It knows too much about different types of boards and it does too much. Furthermore, there's a lot of unnecessary complexity.

This PR tries to move responsibilities into different classes: Standard4p and Standard6p. This can be considered a first step into breaking down complexity. The next step is to remove magic numbers and/or move grid logic into vertex/edge/location classes.

I set the target branch to v3, so v1/v2 is not affected.

• Introduce Standard4p & Standard6p (I anticipate on creating soc.game.board package, so no prefix or suffix is needed
• SOCBoard now abstract
• Move XXX_V1 into Standard4p and XXX_V2 into Standard6p
• Remove static factory method on DefaultBoardFactory -Change implementation of factory to cater to new classes
• Remove boardEncodingFormat field, transition into getBoardEncodingFormat() and have it implemented by the derived classes
• Vector<Integer> variable = new Vector<Integer>() simplified into Vector<Integer> variable = new Vector<>()
• Note that setBoardEncodingFormat call is removed! I'm not too sure if this can be done. Would you mind to check this?

[jdmonin]

Thanks for looking into refactoring this big class. I'm still reviewing your changes, but please watch that refactoring changes and style changes aren't mixed together too much; that can be distracting.

Please remember these things from the project's coding style:

• If you have a long method whose work can be divided into "sections", preface each section with a /** javadoc-style */ multi-line comment. -- In this PR some of those were changed to normal comments.

• Use parentheses around all boolean expressions -- and their parts

• I've now added this to the coding style section, to clarify it: Import individual classes, not entire packages like soc.game.*. Some classes deliberately don't import some others for better separation, especially across packages, or will import a few specific classes for javadocs only.

Thanks again!

[generateui]

Sorry for mixing style changes and structural changes. That does not help reviewing the changeset indeed.

For both the boolean parentheses and /* javadoc / inside methods, I made these changes since they are advised by all my IDE's (Visual Studio, ReSharper, IntelliJ).

Javadoc (/*, 2-star start aka begin-comment delimiter) is used by the Javadoc tool to generate documentation. usually that's for public members, and not used inside a method scope. For this, we should probably use / (single star). Furthermore, we should probably breakup longer methods into smaller ones. YMMV.

Any reason to mandate parentheses in boolean evaluation? I think the reason my IDE's advise against it is because it is shorter and therefore more clear. In my personal style I try to always do single evaluations, like so:

boolean isSettlement = player.settlementToPlace != null;
boolean canPlace = board.canPlace(piece);
boolean placeSettlement = isSettlement && canPlace;
if (placeSettlement) { ... }

instead of

if (player.settlementToPlace != null && board.canPlace(piece)) { ... }

because the first example is much easier to read. Using that style also prevents boolean logic errors caused by incorrect operator precedence placement.

I'll update the changeset.