Reimplement the formula for the balance

The old formula for the balance didn't work out since it didn't react to
deleting expenses, so I had to totally reimplement it.

This is the new correct formula. It consists of cumulative of all of the
previous daily budget and the amount of days they were used + the
overdraft (in case the user chooses to balance the daily budget) - all of
the monthly Expenses.

- create new class DailyBudgetsDataSource, as now I have to keep track of
  the daily budgets that I'm creating because I need them in my formula
- the database is now called budgetcontrol.db instead of expenses, cause
  now it keeps track of daily budgets too
- reimplement the getDailyBudget by just calling the
  getLastDailyBudgetThisMonth() method in the DailyBudgetsDataSource that
  returns the last dailyBudget stored in the database
- create a dailyBudget class along with the needed fields that are used to
  create dailyBudget objects in the DailyBudgetDataSource.
Change how daily budgets are accumulated

Accumulating daily budgets for the balance via the DailyBudgetDataSource
was just too much for the system to do and it caused problems as it worked
inconsistently (I guess, because I was getting the dailyBudget that I just
create too fast).

Now the cumulative dailyBudgets are accumulated via just one variable that
is stored in sharedPreferences. This way the system is doing much less
work.

- reimplement all of the methods in the Balance and Budget classes to
  extract the information from the sharedPreferences instead of the
  database.
- make the instances of Calendar not static since that causes problems
  when switching dates.
- add a bunch of other needed code;
Bug fix: January initialization correct

In case the budget was installed in January there were some problems due
to the fact that sharedPreferences MONTH_BUDGET_DECISION_WAS_MADE key had
a default value of 1. This messed up the logic in case the app was
installed in January. Fixed this by changing the default value to 13, so
that it would not confuse it with any other month.
Bug fix: keep the balance from going negative

Sometimes, due to the loss of precision in doubles and floats in case the
daily budget was balanced - the balance might have still been a very small
negative number which caused the balance overdraft button to pop-up. The
solution is more of a hack for right now - it doesn't compensate the
balance, but rather puts a zero in case it is supposed to be zero. This
issue will be addressed in the later versions.
Limit the number of digits entered in EditTexts

- limit the number of digits to be put in to 9 without decimals and to 7
  with decimals(this will be fixed in futute versions).
Deleted monthly overdraft, formatted the numbers

Removed the monthly budget overdraft functionality for now as it will take
another weeks to implement it correctly and I don't have this time right
now, so it'll have to wait till the next version.

- delete everything related to monthly budget overdraft functionality
- format the numbers accordingly in Progress and Expenses Fragments, so
  that they have thousand separators, which make it better for visual
  comprehension.
limited the size of decimals to two places
Hack: keep the balance 0 after reentering the app

Right now, due to the fact that I'm using floats instead of BigDecimal -
the amounts of money are losing precision. The precision loss is very
small, nevertheless when the daily budget gets balanced and the balance is
supposed to equal zero - it still is somewhat above or below zero (due to
precision loss). This issue will be addressed in the later version by
switching to BigDecimal or longs

- make a hack that will keep the balance at 0 (visually) after
  balancing the daily budget by introducing a DAILY_BUDGET_BALANCED
  boolean variable that will keep the balance at 0 until the user does
  something with the balance in other activities.
Bug fix: expenses are now sorted correctly

Expenses were sorted wrong because the Expense class had a logical error
in the compareTo method.

- fix the compareTo method in the Expense class to implement the correct
  sorting
Bug fix: compare chronological expenses correctly

Before two chronologically preceding expenses were compared by the sum of
their year, month and day. This is not correct they should be compared by
a string of year, month and day as this way it will always be unique,
unlike the sum.

- compare two expenses by the String of year, month and day, instead of
  their sum.
Change color values and assign names
Limit budget setting to 9,999,999.99 of whatever

In order to avoid big precision losses for now I decided to limit the
maximum budget 9,999,999.99 of whatever currency. The issue with precision
will be addressed in later versions.
Add Toast notifications where needed

In order to notify the user about the action that happened, as sometimes
it might not really be noticeable - in case of changin the daily budget,
for example, I decided to implement toast notifications.

- Implement Toast notifications for changing daily budget, monthly budget,
  deleting and saving expenses.
- Write a warning text that will notify the user when changing the monthly
  budget that everything will be reset.
Add two explanation buttons

So that the user gets around quickly at the start of the app - I decided
to implement two explanation buttons.

- Implement explanation buttons that pop-up dialog for the balance and the
  daily budget. They dissapear once they were touched and the user returns
  to the activity.
- Implement them in different layout densities.
Modify the design of the expense list

- put controls to the colors of the expense list in the strings file and
  rename the colors accordingly.
- Make the layout of the expense list more neat.