factored iterator facade stuff into several files

[SVN r19464]

doc/iterator_adaptor_body.rst

@@ -0,0 +1,32 @@
+The ``iterator_adaptor`` class template adapts some ``Base`` [#base]_
+type to create a new iterator.  Instantiations of ``iterator_adaptor``
+are derived from a corresponding instantiation of ``iterator_facade``
+and implement the core behaviors in terms of the ``Base`` type. In
+essence, ``iterator_adaptor`` merely forwards all operations to an
+instance of the ``Base`` type, which it stores as a member.
+
+.. [#base] The term "Base" here does not refer to a base class and is
+   not meant to imply the use of derivation. We have followed the lead
+   of the standard library, which provides a base() function to access
+   the underlying iterator object of a ``reverse_iterator`` adaptor.
+
+The user of ``iterator_adaptor`` creates a class derived from an
+instantiation of ``iterator_adaptor`` and then selectively
+redefines some of the core member functions described in the table
+above. The ``Base`` type need not meet the full requirements for an
+iterator. It need only support the operations used by the core
+interface functions of ``iterator_adaptor`` that have not been
+redefined in the user's derived class.
+
+Several of the template parameters of ``iterator_adaptor`` default to
+``use_default``. This allows the user to make use of a default
+parameter even when the user wants to specify a parameter later in the
+parameter list.  Also, the defaults for the corresponding associated
+types are fairly complicated, so metaprogramming is required to
+compute them, and ``use_default`` can help to simplify the
+implementation.  Finally, ``use_default`` is not left unspecified
+because specification helps to highlight that the ``Reference``
+template parameter may not always be identical to the iterator's
+``reference`` type, and will keep users making mistakes based on that
+assumption.
+