doc: posix: Fix internal links

Fix several links to other Zephyr doc sections as internal.

Signed-off-by: Dmitrii Golovanov <dmitrii.golovanov@intel.com>

doc/services/portability/posix/implementation/index.rst

@@ -18,7 +18,7 @@ Unlike other multi-purpose POSIX operating systems
 .. note::
    Unlike the Linux kernel or FreeBSD, Zephyr does not maintain a static table of system call
    numbers for each supported architecture, but instead generates system calls dynamically at
-   build time. See `System Calls <syscalls>`_ for more information.
+   build time. See `System Calls <syscalls>` for more information.
 
 Design
 ======
@@ -73,5 +73,5 @@ Some general design considerations:
    }
 
 - POSIX API calls should be provided as regular callable C functions; if a Zephyr
-  `System Call <syscalls>`_ is needed as part of the implementation, the declaration and the
+  `System Call <syscalls>` is needed as part of the implementation, the declaration and the
   implementation of that system call should be hidden behind the POSIX API.

doc/services/portability/posix/overview/index.rst

@@ -38,8 +38,8 @@ Benefits of POSIX support in Zephyr include:
 POSIX Subprofiles
 =================
 
-While Zephyr supports running multiple `threads <threads_v2>`_ (possibly in an `SMP <smp_arch>`_
-configuration), as well as `Virtual Memory and MMUs <memory_management_api>`_, Zephyr code and data
+While Zephyr supports running multiple `threads <threads_v2>` (possibly in an `SMP <smp_arch>`
+configuration), as well as `Virtual Memory and MMUs <memory_management_api>`, Zephyr code and data
 normally share a common address space. The Zephyr kernel executable code and the application
 executable code are typically compiled into the same binary artifact. From that perspective, Zephyr
 apps can be seen as running in the context of a single process.