depmod: Rename variable to clarify its meaning

In mod->modnamelen we were actually including the '\0', i.e.
strlen(modname) + 1. So rename it to modnamesz and add a comment in
depmod_module_is_higher_priority() to notice why it's correct since the
new one is really using strlen(modname).
testsuite: add test to fail depmod on module loops
depmod: Add better error messages when facing loops

Since now depmod fails when there are module loops, let's at least give
better error messages, printing the loops we found. Since we may have
more than 1 loop, just printing the modules that are in loop is not
very clear.

Assuming as an example 2 independent loops, this is how the new messages
compare to the old ones:

Before:
	depmod: ERROR: Found 5 modules in dependency cycles!
	depmod: ERROR: /tmp/test-kmod//lib/modules/3.14.4-1-ARCH/kernel/moduleE.ko in dependency cycle!
	depmod: ERROR: /tmp/test-kmod//lib/modules/3.14.4-1-ARCH/kernel/moduleB.ko in dependency cycle!
	depmod: ERROR: /tmp/test-kmod//lib/modules/3.14.4-1-ARCH/kernel/moduleC.ko in dependency cycle!
	depmod: ERROR: /tmp/test-kmod//lib/modules/3.14.4-1-ARCH/kernel/moduleD.ko in dependency cycle!
	depmod: ERROR: /tmp/test-kmod//lib/modules/3.14.4-1-ARCH/kernel/moduleA.ko in dependency cycle!

After:
	depmod: ERROR: Found 5 modules in dependency cycles!
	depmod: ERROR: Cycle detected: moduleE -> moduleD -> moduleE
	depmod: ERROR: Cycle detected: moduleB -> moduleC -> moduleA -> moduleB
testsuite: Add braces
testsuite: Fix expected_fail parsing

If a test has expected_fail=true, it means the return code must be
different from 0 *and* the outputs must match. This way it's possible to
check if the error messages are printed as they should.
testsuite: check for correct error message in detect-loop