Last docs link fixes (#39391)

* should not need <>, but fails without

* adds anchor to keywords page, uses it on plugins pages

* fixes envvar link errors

* harmonize file name and ref name as python_3

* removes undefined-lable from ignore list

docs/docsite/rst/dev_guide/developing_modules.rst

@@ -87,7 +87,7 @@ The following topics will discuss how to develop and work with modules:
      Checklist for contributing your module to Ansible.
 :doc:`testing`
     Developing unit and integration tests.
-:doc:`developing_python3`
+:ref:`developing_python_3`
     Adding Python 3 support to modules (all new modules must be Python-2.6 and Python-3.5 compatible).
 :doc:`developing_modules_in_groups`
     A guide for partners wanting to submit multiple modules.

docs/docsite/rst/dev_guide/developing_modules_checklist.rst

@@ -23,7 +23,7 @@ The following  checklist items are important guidelines for people who want to c
 
 * The shebang must always be ``#!/usr/bin/python``.  This allows ``ansible_python_interpreter`` to work
 * Modules must be written to support Python 2.6. If this is not possible, required minimum Python version and rationale should be explained in the requirements section in ``DOCUMENTATION``.  In Ansible-2.3 the minimum requirement for modules was Python-2.4.
-* Modules must be written to use proper Python-3 syntax.  At some point in the future we'll come up with rules for running on Python-3 but we're not there yet.  See :doc:`developing_python3` for help on how to do this.
+* Modules must be written to use proper Python-3 syntax.  At some point in the future we'll come up with rules for running on Python-3 but we're not there yet.  See :doc:`developing_python_3` for help on how to do this.
 * Modules must have a metadata section.  For the vast majority of new modules,
   the metadata should look exactly like this:
 
@@ -131,8 +131,8 @@ Read the complete :ref:`module metadata specification <ansible_metadata_block>`
   module_utils.urls.fetch_url().  If you use those you may find you also want
   to fallback on environment variables for default values.  If you do that,
   be sure to use non-generic environment variables (like
-  :envvar:`API_<MODULENAME>_USERNAME`).  Using generic environment variables
-  like :envvar:`API_USERNAME` would conflict between modules.
+  :code:`API_<MODULENAME>_USERNAME`).  Using generic environment variables
+  like :code:`API_USERNAME` would conflict between modules.
 
 Windows modules checklist
 =========================

docs/docsite/rst/dev_guide/developing_modules_general_windows.rst

@@ -342,7 +342,7 @@ the most popular are
 To be able to view the arguments as passed by Ansible to the module follow
 these steps.
 
-- Prefix the Ansible command with :envvar:`ANSIBLE_KEEP_REMOTE_FILES=1` to specify that Ansible should keep the exec files on the server.
+- Prefix the Ansible command with :envvar:`ANSIBLE_KEEP_REMOTE_FILES=1<ANSIBLE_KEEP_REMOTE_FILES>` to specify that Ansible should keep the exec files on the server.
 - Log onto the Windows server using the same user account that Ansible used to execute the module.
 - Navigate to ``%TEMP%\..``. It should contain a folder starting with ``ansible-tmp-``.
 - Inside this folder, open the PowerShell script for the module.

docs/docsite/rst/dev_guide/index.rst

@@ -19,7 +19,7 @@ To get started, select one of the following topics.
    developing_plugins
    developing_inventory
    developing_core
-   developing_python3
+   developing_python_3
    developing_api
    developing_rebasing
    testing