Improve issue labeling

[paulobruno]

I would like to improve the current issue labeling by doing the changes proposed below.

1. Create a label improvement, for issues that will make the current code better,
   e.g. Use a proper absolute tolerance in switch function #22;
2. Rename enhancement to newfeature, for issues that add something not currently possible,
   e.g. Save the system solution in a file #24, and Fetching recent data #27;
3. The bug label should be used if and only if the code breaks, such that
   UndefVarError in current version #19 should be a bug, and
   Fluctuations of the Crude Birth Rate variable #60 and Variable initialization incorrect #62 should be improvement;
4. Require (in theory) all issues to have at least one label;
5. All other labels remain as they are now.

The idea is that people can focus on specific types of issues and have some kind of priority evaluation. For example, usually bug is expected to be fixed earlier than newfeature.

If you agree, I will proceed with the changes.

[paulobruno]

As we talked in person, I'm proceeding to change the labels.

[paulobruno]

Because there are some issues in which the result is clearly wrong (like #60 and #78), I'll change the bug rule (number 3 in the first comment).
a. The break label should be used if and only if the code breaks.
b. If the code doesn't break but it's clearly wrong, then we should use bug.
c. Otherwise, it should be improvement.

Unfortunately, the new definition adds an interpretative aspect that I really don't like. But it doesn't seem fair that a wrong result is in the same category as an optimization task.