Multiple independent or layered constructors for TicTacToe?
I would vote for the second, i.e. the one with a basic constructor called by others.

But what is important is how to decide. The criteria that come to mind are:


what if you should refactor later?
which is the most clear when using this class?


In your case, you want to offer different constructors for different usages, with default values in some case.

There are two types of refactoring impacting a constructor: 


fields change
usage changes


Refactoring fields

If the fields change, then you do not have to update 2 (or more) constructors by hand. You first update the lowest level constructor. You can handle the default setting of this field once. If you use an argument and forget to update other constructors, the compiler will let you know.

While if you picked the first option, you will notice you forgot to update all constructors at execution (or test if you have good tests) time.

Refactoring usage

If the usage change, you want to add a new constructor with different arguments. Then you will call another constructor, and all fields will be set since your constructors were correct at first implementation.

Again, if you picked the first option, you would have to set the fields one by one, and there are chances you would not set a field correctly, the compiler would not help you on that.

Clarity

Now let's consider how clear it looks to a user. If you set correctly the visibility (as you did), no option is particularly preferable. Some javadoc would help though, so that the user does not need to open your file. But when reading your file, unless the javadoc is clear, the second option is more confusing, as one should read the whole code to figure what best to use, and what each constructor does, jumping to another method, ...

There might be other criteria that I missed. But from a basic check, the second option seems easier to maintain and be clear enough if some documentation is added. But based on those two criteria, you might conclude differently (you might find clarity more important than later refactoring)