(PDB-675) Stop pdb process even if pidfile missing

Prior to this commit, there were issues about the init.d script failling
silently if the PIDfile was missing. Although the fact that the PIDfile
was missing is a greater issue, this at least provides a workaround for
that. When trying to stop the puppetdb service with a missing PIDfile,
the stop would fail silently, assuming the process had already been
stopped because of the missing PIDfile. However, running `ps auwx | grep
puppetdb` would show that the process has in fact, not been stopped.
This change updated the init.d script to check if the PIDfile is
present before atttempting a stop. If it is, it uses that information to
stop the process as it always has. If it isn't, then it uses the
puppetdb user to stop the process. It is likely that this is too heavy a
hammer to user for this particular problem, but I think it should do
just what we need it do. We still specify --exec when searching for the
process that needs to be stopped, which should limit the possibility of
stopping a process we actually don't want to stop.
@MosesMendoza I guess you could reconstruct something suitable for `--name` with $JAVA_BIN + $JAVA_ARGS.

I guess I'm not as concerned. `--exec` restricts the process kill to only items with java from the output of say `ps -ae`, and `--user` restricts it to the `puppetdb` user.

So the risk in reality is if there might be some other process running java as `puppetdb`, and the only case of where I can think that would be useful is if someone wanted to run multiple copies of puppetdb on the same box. However, I presume that users who want that - are going to construct their own script to do such a thing.

It is true that someone might be crazy enough to run an application on java as the `puppetdb` user, but I would say that would be bad form to begin with and not our responsibility. I guess the other side to this, is that its the fallback behaviour, and will only happen on the rare occasion the pid file is missing. Perhaps we log a warning when this happens?

My main concern atm is that I thought the PID file missing issue was obvious since I had received it so often on IRC I just presumed it was easily reproducible, sorry about that :-(. I've kind of dropped the ball big time on this one. Point being, we might have a way to fix this, but no idea what causes it. No response from PDB-675 yet either.