Fix typos (found by codespell)

Signed-off-by: Stefan Weil <sw@weilnetz.de>

Changelog

@@ -110,7 +110,7 @@ Changes in O.5.4
  - Correct the version strings. (John Ralls)
  - Restore inadvertently-deleted run-install-name-tool tag to bundle files. (John Ralls)
  - Fix translation loop (John Ralls)
- - More descriptive error message for unkown file copying errors (John Ralls)
+ - More descriptive error message for unknown file copying errors (John Ralls)
  - Add an example pygtk bundle (John Ralls)
  - Write Package type into PkgInfo. (John Ralls)
  - Provide a (normally commented out) block which reports each binary file processed so that one can find out which error messages go with which file. (John Ralls)

README.md

@@ -76,7 +76,7 @@ The simple example above works for small and simple applications, but
 often you will need to specify more data to copy in, or to have more
 detailed control over what is copied. 
 
-Here we go through in more depth how this can be acheived. Every file
+Here we go through in more depth how this can be achieved. Every file
 and directory to copy is specified with a source path, and an optional
 destination path. An example that copies an entire directory
 recursively, from the installation prefix:
@@ -174,7 +174,7 @@ The launcher script is used to setup the necessary environment for the
 application to work. If your application does this itself, you can
 leave it out. Many applications will work out of the box with the
 launcher script though. If no script is specified in the tag, a
-default one is used, that sets up the needed environent for most GTK+
+default one is used, that sets up the needed environment for most GTK+
 applications.
 
 Unsurprisingly, the main-binary tag specifies the executable to launch
@@ -217,7 +217,7 @@ in the last path component, for example:
       ${prefix}/lib/gtk/2.10.0/loaders/*.so
     </binary>
 
-An intereseting twist is that some libraries that are built as dylibs
+An interesting twist is that some libraries that are built as dylibs
 are used as loadable modules. Dlopen doesn't have a problem with this,
 it will cheerfully open either. The problem comes because unlike
 Linux, Mac OS X uses different file extensions and formats, so libtool

examples/gtk3-launcher.sh

@@ -100,7 +100,7 @@ elif test -z $LANG -a -f "$I18NDIR/${APPLELOCALE:0:2}/LC_MESSAGES/$APP.mo"; then
     export LANG="${APPLELOCALE:0:2}"
 fi
 
-#Next we need to set LC_MESSAGES. If at all possilbe, we want a full
+#Next we need to set LC_MESSAGES. If at all possible, we want a full
 #5-character locale to avoid the "Locale not supported by C library"
 #warning from Gtk -- even though Gtk will translate with a
 #two-character code.

examples/launcher.sh

@@ -100,7 +100,7 @@ elif test -z $LANG -a -f "$I18NDIR/${APPLELOCALE:0:2}/LC_MESSAGES/$APP.mo"; then
     export LANG="${APPLELOCALE:0:2}"
 fi
 
-#Next we need to set LC_MESSAGES. If at all possilbe, we want a full
+#Next we need to set LC_MESSAGES. If at all possible, we want a full
 #5-character locale to avoid the "Locale not supported by C library"
 #warning from Gtk -- even though Gtk will translate with a
 #two-character code.