Use "third-party" instead of "3rd party"

lib/elixir/lib/calendar/date.ex

@@ -25,7 +25,7 @@ defmodule Date do
 
   Developers should avoid creating the Date structs directly
   and instead rely on the functions provided by this module as well
-  as the ones in 3rd party calendar libraries.
+  as the ones in third-party calendar libraries.
 
   ## Comparing dates
 

lib/elixir/lib/calendar/datetime.ex

@@ -14,7 +14,7 @@ defmodule DateTime do
 
   Developers should avoid creating the `DateTime` struct directly
   and instead rely on the functions provided by this module as
-  well as the ones in 3rd party calendar libraries.
+  well as the ones in third-party calendar libraries.
 
   ## Where are my functions?
 
@@ -25,7 +25,7 @@ defmodule DateTime do
   of Elixir.
 
   Such may be addressed in upcoming versions, meanwhile,
-  use 3rd party packages to provide `DateTime` building and
+  use third-party packages to provide `DateTime` building and
   similar functionality with time zone backing.
   """
 

lib/elixir/lib/calendar/naive_datetime.ex

@@ -30,7 +30,7 @@ defmodule NaiveDateTime do
 
   Developers should avoid creating the NaiveDateTime structs directly
   and instead, rely on the functions provided by this module as well
-  as the ones in 3rd party calendar libraries.
+  as the ones in third-party calendar libraries.
 
   ## Comparing naive date times
 

lib/elixir/lib/calendar/time.ex

@@ -25,7 +25,7 @@ defmodule Time do
 
   Developers should avoid creating the Time structs directly
   and instead rely on the functions provided by this module as well
-  as the ones in 3rd party calendar libraries.
+  as the ones in third-party calendar libraries.
 
   ## Comparing times
 

lib/elixir/lib/port.ex

@@ -127,7 +127,7 @@ defmodule Port do
   While most UNIX command line tools will exit once its communication channels
   are closed, not all command line applications will do so. While we encourage
   graceful termination by detecting if stdin/stdout has been closed, we do not
-  always have control over how 3rd party software terminates. In those cases,
+  always have control over how third-party software terminates. In those cases,
   you can wrap the application in a script that checks for stdin. Here is such
   script in Bash:
 

lib/ex_unit/lib/ex_unit/case.ex

@@ -435,7 +435,7 @@ defmodule ExUnit.Case do
   @doc """
   Registers a function to run as part of this case.
 
-  This is used by 3rd party projects, like QuickCheck, to
+  This is used by third-party projects, like QuickCheck, to
   implement macros like `property/3` that works like `test`
   but instead defines a property. See `test/3` implementation
   for an example of invoking this function.

lib/mix/lib/mix/tasks/new.ex

@@ -276,7 +276,7 @@ defmodule Mix.Tasks.New do
   # The directory Mix downloads your dependencies sources to.
   /deps/
 
-  # Where 3rd-party dependencies like ExDoc output generated docs.
+  # Where third-party dependencies like ExDoc output generated docs.
   /doc/
 
   # Ignore .fetch files in case you like to edit your project deps locally.
@@ -392,7 +392,7 @@ defmodule Mix.Tasks.New do
   # to this project. If another project depends on this project, this
   # file won't be loaded nor affect the parent project. For this reason,
   # if you want to provide default values for your application for
-  # 3rd-party users, it should be done in your "mix.exs" file.
+  # third-party users, it should be done in your "mix.exs" file.
 
   # You can configure your application as:
   #
@@ -402,7 +402,7 @@ defmodule Mix.Tasks.New do
   #
   #     Application.get_env(:<%= @app %>, :key)
   #
-  # You can also configure a 3rd-party app:
+  # You can also configure a third-party app:
   #
   #     config :logger, level: :info
   #