[lld][NFC] Inclusive language: rename master graph in lld docs

[quinnp]

Summary

[NFC] As part of using inclusive language within the llvm project, this patch
renames the master graph referenced in lld/docs/design.rst to main graph.

[MaskRay]

These documents are quite outdated. I suggest we just remove them in D113432.

[quinnp]

In D113402#3116604, @MaskRay wrote:

These documents are quite outdated. I suggest we just remove them in D113432.

Thanks! That sounds good, I'll abandon this patch.

lld/docs/design.rst

 expected by the linker.
 
 Object File
 ~~~~~~~~~~~
 
 An object file is just a container of atoms.  When linking an object file, a
 reader is instantiated which parses the object file and instantiates a set of
 atoms representing all content in the .o file.  The linker adds all those atoms
-to a master graph.
+to a main graph.
 
 Static Library (Archive)
 ~~~~~~~~~~~~~~~~~~~~~~~~
 
 This is the traditional unix static archive which is just a collection of object
 files with a "table of contents". When linking with a static library, by default
-nothing is added to the master graph of atoms. Instead, if after merging all
-atoms from object files into a master graph, if any "undefined" atoms are left
-remaining in the master graph, the linker reads the table of contents for each
+nothing is added to the main graph of atoms. Instead, if after merging all
+atoms from object files into a main graph, if any "undefined" atoms are left
+remaining in the main graph, the linker reads the table of contents for each
 static library to see if any have the needed definitions. If so, the set of
 atoms from the specified object file in the static library is added to the
-master graph of atoms.
+main graph of atoms.
 
 Dynamic Library (Shared Object)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Dynamic libraries are different than object files and static libraries in that
 they don't directly add any content.  Their purpose is to check at build time
 that the remaining undefined references can be resolved at runtime, and provide
 a list of dynamic libraries (SO_NEEDED) that will be needed at runtime.  The way
 this is modeled in the linker is that a dynamic library contributes no atoms to
 the initial graph of atoms.  Instead, (like static libraries) if there are
-"undefined" atoms in the master graph of all atoms, then each dynamic library is
+"undefined" atoms in the main graph of all atoms, then each dynamic library is
 checked to see if exports the required symbol. If so, a "shared library" atom is
 instantiated by the by the reader which the linker uses to replace the
 "undefined" atom.
 
 Linking Steps
 -------------
 
 Through the use of abstract Atoms, the core of linking is architecture
 independent and file format independent.  All command line parsing is factored
 out into a separate "options" abstraction which enables the linker to be driven
 with different command line sets.
 
 The overall steps in linking are:
 
   #. Command line processing
 
   #. Parsing input files
 
   #. Resolving
 
   #. Passes/Optimizations
 
   #. Generate output file
 
-The Resolving and Passes steps are done purely on the master graph of atoms, so
+The Resolving and Passes steps are done purely on the main graph of atoms, so
 they have no notion of file formats such as mach-o or ELF.
 
 
 Input Files
 ~~~~~~~~~~~
 
 Existing developer tools using different file formats for object files.
 A goal of lld is to be file format independent.  This is done
 through a plug-in model for reading object files. The lld::Reader is the base
 class for all object file readers.  A Reader follows the factory method pattern.
 A Reader instantiates an lld::File object (which is a graph of Atoms) from a
 given object file (on disk or in-memory).
 
 Every Reader subclass defines its own "options" class (for instance the mach-o
 Reader defines the class ReaderOptionsMachO).  This options class is the
 one-and-only way to control how the Reader operates when parsing an input file
 into an Atom graph.  For instance, you may want the Reader to only accept
 certain architectures.  The options class can be instantiated from command
 line options, or it can be subclassed and the ivars programmatically set.
 
 Resolving
 ~~~~~~~~~
 
 The resolving step takes all the atoms' graphs from each object file and
-combines them into one master object graph.  Unfortunately, it is not as simple
+combines them into one main object graph.  Unfortunately, it is not as simple
 as appending the atom list from each file into one big list.  There are many
 cases where atoms need to be coalesced.  That is, two or more atoms need to be
 coalesced into one atom.  This is necessary to support: C language "tentative
 definitions", C++ weak symbols for templates and inlines defined in headers,
 replacing undefined atoms with actual definition atoms, and for merging copies
 of constants like c-strings and floating point constants.
 
 The linker support coalescing by-name and by-content. By-name is used for