Yes, they will, if they use a higher version number than your packages, unless you adjust your pin priorities appropriately (or hold the packages, as pointed out by cas). Note that the repositories’ packages are liable to overwrite yours if you use the same version number, so you should really increment your version when you rebuild locally (typically “1.1.8-3ubuntu1.1”).
No, and you should avoid it unless absolutely necessary. If you think it’s necessary, there’s probably something wrong with your packages and you should fix that instead.
That code repository hasn’t been updated since 2014, so I doubt it’s an active development repository. You can see the various pam branches on Launchpad, and clone them using for example bzr branch lp:ubuntu/vivid/pam.
The way I go about dealing with this type of situation is as follows:
check out the source code (debcheckout or apt-get source)
if it’s in a repository, create a new branch with the patch I’m interested in
if it’s not, apply the patch manually
in both cases, increment the version with an appropriate changelog entry using dch -n (without committing it, to avoid merge issues)
build the package and install it (in my case, via a local package repository)
When a new version of the package is released, I repeat the above; in the case of a source repository, I rebase the patch instead of starting from scratch.
apt-mark hold libpam0g libpam0g-dev libpam-cracklib libpam-doc libpam-modules libpam-modules-bin libpam-runtime(and unhold them with
apt-mark unhold ...). This will probably cause numerous other packages that depend on newer pam packages to also be held. You're better off downloading the source package for the new version of pam, patching it again, compiling and installing. Then use apt-mark to hold them (until the next time this needs to be done).