Bring back log message levels

[stump]

These were removed with the glib removal. They should be restored.

(Some discussion of this point took place in #1.)

ABI-bump-related, so this goes on branch libsmf1.

[stump]

They're brought back now, though I want to make another pass through them to ensure the levels are really appropriate.

[przemoc]

Allow me to repeat what I already wrote in issue #1 and extend it a bit in the context of your recent commit 21f5c1a4.

I suggest changing smf_warn(const char *fmt, ...) to smf_msg(int level, const char *fmt, ...) and introducing enum for commonly used levels (descending importance order): CRITICAL, ERROR, WARNING, INFO, DEBUG. Then warning handler should be changed to message handler that would receive additionally the level information, obviously.

1. I think it is cleaner to have one smf_msg() or smf_log() function than bunch of these smf_critical(), smf_debug(), etc. like glib has.
2. Current log levels mimic these provided by glib, but glib has its own strange choices, so I'm not sure it is good example to follow. In most loggers out there severity of CRITICAL (sometimes called FATAL) level is higher (well, as the name implies it after all, unless you're glib developer :P) than ERROR, as it stands for critical/fatal error. Some examples Python's Logging HOWTO, Ruby's Logger, Boost.Log, Trac Logging, and so on...

I understand your concern about people migrating from older lib version, but fixing the level order (which would mean changing glib-ish CRITICAL into ERROR and improving comment next to smf_log_level enum explaining it) is not really a problem, as a drop-in glib-based log handler can be easily provided if needed.

Lack of proper CRITICAL/FATAL (i.e. what glib strangely calls ERROR), even if we're doing a lib, is actually debatable, because failed malloc() is usually CRITICAL, so I would raise level of such messages.

---

(Sorry for only talking without giving you any pull requests, maybe there will be a time, when I'll have spare time to participate more actively in the project, but I believe that discussions can be as valuable as code and sometimes even more.)