More consistent formatting of examples in documentation

Doc/Manual/Python.html

@@ -2565,9 +2565,9 @@ the function callback in the tp_hash slot for the builtin type for <tt>MyClass</
 <div class="code">
 <pre>
 static PyHeapTypeObject SwigPyBuiltin__MyClass_type = {
-    ...
-    (hashfunc) myHashFunc,       /* tp_hash */
-    ...
+  ...
+  (hashfunc) myHashFunc,       /* tp_hash */
+  ...
 </pre>
 </div>
 
@@ -3087,7 +3087,7 @@ references. Here is an example:
 <pre>
 class Foo {
 public:
-    ...
+  ...
 };
 class FooContainer {
 public:

Doc/Manual/SWIG.html

@@ -389,7 +389,7 @@ For example
 /* bar not wrapped unless foo has been defined and 
    the declaration of bar within foo has already been parsed */
 int foo::bar(int) {
-    ... whatever ...
+  ... whatever ...
 }
 </pre>
 </div>

Doc/Manual/SWIGPlus.html

@@ -706,7 +706,7 @@ class Foo {
 protected:
   Foo();         // Not wrapped.
 public:
-    ...
+  ...
 };
 </pre>
 </div>
@@ -1278,7 +1278,7 @@ equivalent to one generated for the following declaration
 <pre>
 class Foo {
 public:
-    ...
+  ...
 };
 
 void blah(Foo *f);    
@@ -4381,9 +4381,9 @@ class Error { };
 
 class Foo {
 public:
-    ...
-    void blah() throw(Error);
-    ...
+  ...
+  void blah() throw(Error);
+  ...
 };
 </pre>
 </div>
@@ -4547,7 +4547,7 @@ class Foo_Impl {
 public:
   int x;
   virtual void bar();
-    ...
+  ...
 };
 
 // Smart-pointer wrapper

Doc/Manual/Varargs.html

@@ -423,8 +423,8 @@ Variable length arguments may be used in typemap specifications.  For example:
 <div class="code">
 <pre>
 %typemap(in) (...) {
-    // Get variable length arguments (somehow)
-    ...
+  // Get variable length arguments (somehow)
+  ...
 }
 
 %typemap(in) (const char *fmt, ...) {