Added primary key to Person as our first internal state field to track and save

[podocarp]

• Created new InternalState* classes to track and store the internal state of the program
• Examples of internal states:
  • Command history
  • Primary keys of other thingawumuts
  • etc.

The UserPrefs now store one more path, that is the path of the internal state save file. By default it is data/state.json.

The only things that need to be touched when adding more fields in is the {update, apply}InternalState functions. Be sure to update them!

[daekoon]

Mostly ok, but we should at least do this before merging:

• Update test helper classes PersonBuilder. Add in a method to set primaryKey.
• Change the naming of the primaryKeyCounter to be more specific towards Person class.

These should be future sprint enhancements:

• Tests for InternalStorage and related classes (low priority)
• Validation to check if primaryKeyCounter for InternalStorage is valid upon file load. (Higher priority)

[podocarp]

* Update test helper classes `PersonBuilder`. Add in a method to set `primaryKey`.

primarykey being exposed is quite contentious. Some points about the behavior now:

• Person.equals does not care about primary key.
• PersonBuilder constructor can be made to copy the primary key.
• PersonBuilder.build() calls a constructor of Person which does not care about the primary key.

So it is quite messy. I will add some tests for other behavior, but I don't think I will ever want to change the equals behavior. For sure the primary key will be different, what's there to check (it's validated on start)? And so it follows that if equals behaves like this, the other functions can do anything they want, but nothing will change. e.g. PersonBuilder.build() can use any constructor it wants and nothing will change.

* Tests for `InternalStorage` and related classes (low priority)

Done

* Validation to check if `primaryKeyCounter` for `InternalStorage` is valid upon file load. (Higher priority)

Done

[daekoon]

Good job for catching those edge cases regarding .equal method for Person class. Should document it in the Developer guide in the future.
Personally I think your equal method is ok - it should be comparing the content of the Person object, and I would argue that primaryKey isn't really a content , but an identity of that object and hence shouldn't be used for .equal comparison (similar to how hashcode doesn't get compared)

[liakify]

Looks good to me