commitpkg: behavior more sanely in searching for built pkgs

In the case of a .pkg.tar.xz and a .pkg.tar.gz existing in the same
directory, all commitpkg would say is:

  ==> WARNING: Could not find . Skipping x86_64

Upon digging into the logic, we did a few things poorly, mostly in
getpkgfile:

- getpkgfile tried to die in a subshell (within the command substituion
  assignment to 'pkgfile'). This will never work.
- We assumed that proper glob expansion happened when we received
  exactly 1 arg. This isn't necessarily true without nullglob in effect.
- We dumped the real error (spewed by getpkgfile) to /dev/null.
- We checked for the package twice in both $PWD and $DESTDIR/.
- We checked for file existance multiple times.

Address this by:

- not hiding errors. revamp the wording a little bit to make it more
  obvious why we failed, particularly in the case of a glob expanding to
  more than 1 file. Logic here is simplified to pointing out the failure
  cases of 0 and >1.
- setting nullglob so the number of arguments passed into getpkgfile is
  meaningful from a 'did it decisively resolve' point of view.
- not trying to exit the entire script from a subshell. Just return a
  value (and use it).
- avoiding the package file existance check afterwards. this is a
  freebie from getpkgfile when the glob passed fails to expand.

Signed-off-by: Dave Reisner <dreisner@archlinux.org>
Signed-off-by: Pierre Schmitz <pierre@archlinux.de>