[1772] used ::1 instead of 127.0.0.1 2nd bind10 instance and the example test.

127.0.0.1:47807 is used by a MacOS application and the conflict makes the
test fail in environments that uses the app.  Using an IPv6 address is not
a cleanest solution, but unless we make it fully configurable we need to
handle this type of thing by some workaround anyway.  Also, I believe
it's good to use IPv6 transport for some tests in any event.

tests/lettuce/configurations/example2.org.config

@@ -12,7 +12,7 @@
         "database_file": "data/example.org.sqlite3",
         "listen_on": [ {
             "port": 47807,
-            "address": "127.0.0.1"
+            "address": "::1"
         } ]
     }
 }

tests/lettuce/features/example.feature

@@ -133,10 +133,10 @@ Feature: Example feature
         Then wait for bind10 auth of bind10_one to start
         Then wait for bind10 auth of bind10_two to start
         A query for www.example.org to 127.0.0.1:47806 should have rcode NOERROR
-        A query for www.example.org to 127.0.0.1:47807 should have rcode NOERROR
+        A query for www.example.org to [::1]:47807 should have rcode NOERROR
 
         Then set bind10 configuration Auth/database_file to data/empty_db.sqlite3
         And wait for bind10_one stderr message DATASRC_SQLITE_OPEN
 
         A query for www.example.org to 127.0.0.1:47806 should have rcode REFUSED
-        A query for www.example.org to 127.0.0.1:47807 should have rcode NOERROR
+        A query for www.example.org to [::1]:47807 should have rcode NOERROR