Better namespace handling in generated code / ModuleDefs

Consider this contrived module.

use spacetime::*;

pub mod gems {
    use super::*;

    #[derive(SpacetimeType)]
    pub enum Gem {
        Diamond,
        WorthlessGlass,
    }

    #[derive(SpacetimeType)]
    pub struct Inventory(Vec<Gem>);
}

pub mod fruit {
    use super::*;

    #[derive(SpacetimeType)]
    pub enum Fruit {
        Apple,
        Banana,
    }

    #[derive(SpacetimeType)]
    pub struct Inventory(Vec<Fruit>);
}

#[spacetimedb(table(public))]
pub struct Person {
    #[primarykey]
    #[autoinc]
    id: u32,
    name: String,
    age: u8,
    gems: gems::Inventory,
    fruit: fruit::Inventory,
}

I believe this module will compile and upload fine. However, if you attempt to generate a client for it, the client will have compile errors.

This is because of how type names are registered on ModuleDef. Types implement SpacetimeType::make_type which calls the TypespaceBuilder::add method. They call this with their name, which is a single identifier, not a sequence of identifiers.

So, both Inventory structs above will register themselves with exactly the same name, Inventory. This may result in name collisions when you generate a client.

Start with ModuleDef, SpacetimeType::make_type, and TypespaceBuilder::add to trace how type names are registered. Determine how namespace-qualified names should be represented and propagated into generated clients. Done means modules containing same-named types in different namespaces generate clients without compile-time name collisions.