Rename DefCore Committee -> Interop Working Group

At the Board of Directors meeting on April 24, 2016 the Board of
Directors indicated that as DefCore has evolved it's focus on
interoperability and it's working structure, it's name may be a
source of some confusion to those outside of the community or who are new
to the community.  The Board made an informal request that the DefCore
Committee consider changing it's name to more clearly reflect it's
focus and structure.  In August of 2016, the Board passed a resolution
renaming the group to "The Interop Working Group".[1]

Since then, the Interop Working Group has completed a series of changes
to it's documentation and public resources to reflect it's new name.[2]
The next step in the process is to rename the project's resources in
infra, including it's git repository and associated artifacts.[3]  This
This commit modifies a few remaining governance artifacts that referece
DefCore to use the new name/artifacts instead.  Past TC resolutions
referencing DefCore have been ommitted to preserve historical context.

[1] https://wiki.openstack.org/wiki/Governance/Foundation/23Aug2016BoardMinutes
[2] For example: http://git.openstack.org/cgit/openstack/defcore/commit/?id=d8fb682a2bd17c111f5dd4f8341fb1b300ac2d4d
[3] https://review.openstack.org/433414

Change-Id: I4f5d415f31c9976a001e318c7ae4dc9f9651e215

reference/foundation-board-repos.yaml

@@ -1,7 +1,7 @@
 ---
 # List of repositories owned by Foundation board and subcommittes
-DefCore subcommittee:
-  - repo: openstack/defcore
+Interop Working Group:
+  - repo: openstack/interop
 
 Transparency subcommittee:
   - repo: openstack/transparency-policy

reference/projects.yaml

@@ -4220,7 +4220,7 @@ RefStack:
   service: Interoperability Test Report
   mission: >
     RefStack is a test result collection and reporting service to support the
-    DefCore interoperability testing process.
+    Interop Working Group interoperability testing process.
   url: https://wiki.openstack.org/wiki/RefStack
   deliverables:
     refstack:

reference/tags/assert_follows-standard-deprecation.rst

@@ -62,10 +62,10 @@ features deprecation:
    the cost is then very related to the number of people using the feature
    and how dependent they are to that feature.
 
-#. If the deliverable is part of a defcore set, the project will check if the
-   deprecated feature is part of the exposed capabilities. If it is, the
-   obsolescence date (see below) additionally needs to take into account
-   defcore capabilities deprecation schedule.
+#. If the deliverable is part of an Interop Working Group Guideline, the
+   project will check if the deprecated feature is part of the exposed
+   capabilities. If it is, the obsolescence date (see below) additionally
+   needs to take into account Interop WG capabilities deprecation schedule.
 
 #. Based on that data, an obsolescence date will be set. At the very minimum
    the feature (or API, or configuration option) should be marked deprecated