xso: add support for overriding names of generated types

In 1265f4b, we introduced a change which may cause a conflict of type
names when deriving the traits on two different types. While a
workaround existed (use `mod`s to isolate the implementation), that is
ugly.

This commit allows overriding the choice of type names.

xso/ChangeLog

@@ -2,20 +2,16 @@ Version NEXT:
 0000-00-00 Jonas Schäfer <jonas@zombofant.net>
     * Breaking
       - We now strip trailing underscores from identifiers before constructing
-        any type names we declare from derive macros. That means that it is
-        not possible to derive the traits on `Foo` and `Foo_` if both live
-        in the same scope.
+        any type names we declare from derive macros.
 
-        As a workaround, you can put either of these types into a `mod` and
-        reexport them from the outer module. The types generated by the derive
-        macro will then be scoped inside the `mod` and cannot conflict with
-        the derived types on the other type.
-
-        All this is to avoid triggering the camel case lint on the types we
-        generate.
+        If you previously derived any of the macros on e.g. `Foo` and `Foo_`
+        within the same scope, you can use the newly added `builder` and
+        `iterator` meta keys to override the generated type names.
     * Added
       - Support for child elements in derive macros. Child elements may also
         be wrapped in Option or Box.
+      - Support for overriding the names of the types generated by the derive
+        macros.
 
 Version 0.1.2:
 2024-07-26 Jonas Schäfer <jonas@zombofant.net>