create-diff-object: don't create __fentry__ dynrelas

This fixes the following issue for a patch which changes a module:

  kpatch_create_mcount_sections: 1968: bad first rela in .rela.text.e_show

The first rela is "bad" because the real first rela was converted to a
dynrela and then removed from the rela list.

This is a temporary fix.  The more permanent fix should be to allow
lookups in vmlinux for patched modules so we don't create any
unnecessary dynrelas.
Rebase of SPEC file to current version
kpatch-build: extract GCC version from .comment section

Extract the GCC version from the .comment section of vmlinux.  This
hopefully makes the version check more robust across various distros.

Fixes #297.
Merge pull request #300 from jpoimboe/gcc-version-readelf

kpatch-build: extract GCC version from .comment section
Merge pull request #298 from jpoimboe/no-fentry-dynrela

create-diff-object: don't create __fentry__ dynrelas
Merge pull request #299 from useidel/master

Rebase of SPEC file to current version
README.md: add debian support
README.md: add build-essential package
kmod/core: check force flag in replace case

When unpatching a function due to "kpatch replace", check the force flag
before doing the activeness safety check.
Merge pull request #304 from jpoimboe/force-fix

kmod/core: check force flag in replace case
Merge pull request #302 from goldyfruit/master

README.md: add debian support
prevent rmmod of forced modules

I found a bad bug:

- Module A is loaded, and registers function foo() with
  KPATCH_FORCE_UNSAFE.
- Module A is unloaded.  The new version of foo() is on the backtrace of
  a task, but the core module ignores it because of the force flag, so
  the unloading succeeds.
- The task returns to the new version of foo() which no longer exists.
- BOOM.

The only way I can think of to prevent this scenario is to prevent
forced modules from being unloaded (but still allow them to be
disabled).

An annoying side effect of this approach is that forced modules stay
loaded and in memory forever.  And that after "kpatch unload" of a
forced module, you can't ever load it again because the previous
instance of it is still loaded (but permanently disabled).

This is ugly but I can't really think of a better way to handle it.  If
necessary we could create a workqueue and periodically check to see if
we can safely call module_put() so that the module could be eventually
removed.
code review fix

Return 0 on rmmod error.
Merge pull request #305 from jpoimboe/force-prevent-rmmod

prevent rmmod of forced modules
Fix merge conflicts