ref-manual, dev-manual: Clarification of "native" and "sdknative"

Fixes [YOCTO #8620]

I went through and made some judgement calls on the use of
"native" and "sdknative".  I tried to make sure that the reader
understood the real meaning of these terms.

(From yocto-docs rev: d711e8c6dfb32a4ad79e9d11dbf44fbc759d0245)

Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

documentation/dev-manual/dev-manual-common-tasks.xml

@@ -3603,10 +3603,11 @@
                 <title>Additional Implementation Details</title>
 
                 <para>
-                    Different packaging systems have different levels of native Multilib
-                    support.
-                    For the RPM Package Management System, the following implementation details
-                    exist:
+                    Different packaging systems have different levels of
+                    native Multilib support (i.e. support for the host build
+                    machine).
+                    For the RPM Package Management System, the following
+                    implementation details exist:
                     <itemizedlist>
                         <listitem><para>A unique architecture is defined for the Multilib packages,
                             along with creating a unique deploy folder under
@@ -3823,7 +3824,8 @@
                         in the form generated by the build system.
                         </para></listitem>
                     <listitem><para>
-                        You must build several native tools:
+                        You must build several native tools, which are tools
+                        built to run on the build system:
                         <literallayout class='monospaced'>
      $ bitbake parted-native dosfstools-native mtools-native
                         </literallayout>
@@ -6375,8 +6377,9 @@
                     developers when building for multiple machines.
                     When you use the same <filename>TMPDIR</filename> for
                     multiple machine builds, the OpenEmbedded build system can
-                    reuse the existing native and often cross-recipes for
-                    multiple machines.
+                    reuse the existing native (i.e. host system) and often
+                    cross-recipes (i.e. <filename>nativesdk</filename>
+                    for multiple machines.
                     Thus, build time decreases.
                     <note>
                         If
@@ -7583,6 +7586,7 @@
                             run the test suite by using a single command
                             such as <filename>make check</filename>.
                             However, the native <filename>make check</filename>
+                            that runs on the host system
                             builds and runs on the same computer, while
                             cross-compiling requires that the package is built
                             on the host but executed on the target.
@@ -8169,7 +8173,8 @@
                         specific to or dependent on the target
                         architecture:</emphasis>
                         You can work around these attempts by using native
-                        tools to accomplish the same tasks, or
+                        tools, which run on the host system,
+                        to accomplish the same tasks, or
                         by alternatively running the processes under QEMU,
                         which has the <filename>qemu_run_binary</filename>
                         function.