Change Command class to DbCommand class

Why is this change necessary?
CommandParser class (written by Andrew) took the main role of processing
and executing parsed commands. Command log management for undo/redo will
also be handled by Logic class. Thus, the previously written Command
class is now useful only for storage within database in the events of
failed synchronisation with Google Calendar, e.g. user is offline.
Therefore it's more appropriate to rename Command class to DbCommand,
where 'Db' stands for 'Database'.

What side effects does this change have?
Database will now need to use rename Command objects to DbCommand
objects.
Remove useless methods in DbCommand class

Why is this change necessary?
Since DbCommand objects are used for storing unsynced (with Google
Calendar) commands, there is no need for methods like setTask(); the
task associated with the command (add/delete) should be initialised from
the constructor and remain unchanged. Also, I'm thinking of using
polymorphism for getting different behaviours out of add and delete
commands, so there's no need for the commandType field.

What side effects does this change have?
Implement polymorphism for different types of commands, specifically add
and delete commands for now, for the unsynced command stack of database.
Merge branch 'master' into database
Group relevant classes into database package

Why is this change necessary?
For better organisation of database-associated classes.

What side effects does this change have?
- Developers wanting to use classes under the taskbuddy.database package
  have to now import the latter.
- All classes in taskbuddy.database have to be public, otherwise other
  developers in the same project cannot use the database classes.