Bump version to 1.2.0 and prepare 1.3.0 development cycle.

Notes from the original PR:

The dependencies for android in autobuild can not be installed in
pdf-tools-install, they have to be installed manually in Termux. But
the dependencies are checked when running autobuild.

pdf-tools-install successfully installs epdfinfo in Android Emacs. One
can then view pdf files.

The shebang in autobuild does not work in Termux, I therefore had to
create a separate script "autobuild.android" that in turn executes
autobuild. The problem with the shebang is that "env" in Termux is not
located at "/usr/bin/env".

pdf-tools/Makefile does currently not work in Android Emacs, but it is
not needed for running pdf-tools-install. Fixing this will have to be
done in a separate pull request, if deemed necessary. Reason: There is
yet no consensus for how to implement a command line emacs, to be run
in batch mode, in Android Emacs.

I have successfully run "make test" in Ubuntu, in the repo feature
branch. Running "make server-test" in the master branch fails, so I
have not tested this in the feature branch.

Closes: #230
Author: @johanwiden

These variables' default values should match the :type given in their
definitions, or else M-x customize will display a warning or may even
fail to initialize properly.

The first attempt at this workaround was
c451c0e3db5b367d191bddf428e38fd8a21c0102 , which did not work
because (my guess) `pdf-tools-enabled-modes` would be evaluated before
the theme was loaded. This is attempt 2, which sets this value in the
`pdf-view-mode` function itself.

This is meant as a workaround for #166 (which see).

Best guess about what is happening and why this workaround works comes
from @d8660091 (lightly edited):

> I'm using M2 and I can reproduce the issue with just the following
> snippets I extracted from pdf-isearch-current-colors, which was
> invoked during a pdf isearch:

    (add-hook 'pdf-tools-enabled-hook
               (lambda ()
                 (pdf-util-face-colors 'pdf-isearch-match nil)
                 (pdf-util-face-colors 'pdf-isearch-lazy nil)))

> And run `pdf-tools-install`

> I tried adding `(sit-for 1)` before `(delete-frame f)`, the crash
> was gone.

> But I am still not sure what's really happening.

> I think `pdf-view-dark-minor-mode` works because new frame is not
> created and `delete-frame` doesn't happen.

If anyone has an idea about what is happening here and what the
correct way to fix it is, please get in touch via the linked issue!

This is meant as a workaround for #166 (which see).

Best guess about what is happening and why this workaround works comes
from @d8660091 (lightly edited):

> I'm using M2 and I can reproduce the issue with just the following
> snippets I extracted from pdf-isearch-current-colors, which was
> invoked during a pdf isearch:

    (add-hook 'pdf-tools-enabled-hook
               (lambda ()
                 (pdf-util-face-colors 'pdf-isearch-match nil)
                 (pdf-util-face-colors 'pdf-isearch-lazy nil)))

> And run `pdf-tools-install`

> I tried adding `(sit-for 1)` before `(delete-frame f)`, the crash
> was gone.

> But I am still not sure what's really happening.

> I think `pdf-view-dark-minor-mode` works because new frame is not
> created and `delete-frame` doesn't happen.

If anyone has an idea about what is happening here and what the
correct way to fix it is, please get in touch via the linked issue!

Closes: #166

This is necessary because the extensive changes in `epdfinfo` do not
get picked up by third party package management systems unless they
enter Melpa Stable.

This mismatch caused a number of issues, which I expect this bump will
now fix. Thanks to @cyrilarnould and @barslmn for pointing this out.

I am also using this bump to close long-open install issues. The idea
here is that these issues are being lost. I would rather everyone
upgrade to the latest versions of `pdf-tools` and `epdfinfo` and then
re-report the issues if they still exist.

Please note: as of this release, users are not expected to manually
set anything on their machines during installation. (for example:
`$PKG_CONFIG_PATH`). The installation should *just work*. If it does
not, please open a ticket so that we can track it.

Fixes: #213
Closes: #177
Closes: #216

All the code working around issues in Emacs 24 and Emacs 25 has been
removed at this point! (or at least, as much of it as I could find)

I've tested against Emacs 28 and it's working fine. I need many more
automated tests to ensure that behaviour does not break across
multiple Emacs versions / operating systems, but that is a topic for
another day.

This commit bumps the version of `pdf-tools` from `1.0.0snapshot` to
`1.0.0`. I do not expect this to have any real change either on Melpa
Stable or Non-GNU Elpa, since they already parse the version as 1.0.0.

I am not creating a tag at the moment. I will do some more cleanup
work and directly create a `1.1.0` post those changes.

Closes: #26

I am not sure how to 'consistently' reproduce the issue that this
commit fixes. But I was experiencing the issue as reported at
https://github.com/syl20bnr/spacemacs/issues/15106, where for some
reason `pdf-view-mode` did not open in evil `evilified-state`.

After (a long time of) hunting down the cause, I found that
`pdf-tools` (silently) errors when the `buffer-list` contains killed
buffers. The error occurs because `pdf-tools-install-noverify` calls
`with-current-buffer` with the killed buffer. This commit simply adds
the `buffer-live-p` check before the `with-current-buffer` form gets
called.

Closes: #93
Potentially Fixes: syl20bnr/spacemacs#15106
Author: @dalanicolai