Improve the `ClientId` ergonomics for listen servers

[malfuu]

I wanted to propose adding the server as a client entity, a feature that would reduce listen-server exclusive code.

My change would be turning ClientId into:

pub enum ClientId {
    Client(Entity),
    Server(Entity),
}

Allowing for entity() to change into:

impl ClientId {
    pub fn entity(self) -> Entity {
        match self {
            ClientId::Client(entity) => entity,
            ClientId::Server(entity) => entity,
        }
    }
}

This could also reduce boilerplate when retrieving player information, where as before:

#[derive(Event)]
struct PrintPlayerName;

fn print_name(
    event: On<FromClient<PrintPlayerName>>,
    players: Query<&Name>,
    server_player: Local<Entity> // assume it is correctly initialized
) {
    // long chain to obtain a player entity (and even then its assuming ServerEntity always exists)
    let player_entity = event.client_id.entity().unwrap_or(**server_player);

    info!("{}", players.get(player_entity).unwrap());
}

Can be turned into:

fn print_name(
    event: On<FromClient<PrintPlayerName>>,
    players: Query<&Name>,
) {
    let player_entity = event.client_id.entity(); // using the new impl of entity()

    info!("{}", players.get(player_entity).unwrap());
}

I could see this being more useful in:

• Reducing boilerplate where per-player components/relationships matter
• Visibility rules being applied in the listen server instance (instead of despawning entities, Visibility is togggled)

Although, this would impose a requirement to the backend to provide its client entity for the server instance, I think it is a fair price to pay for listen-servers. I wanted to know what you think of this idea, because we can both agree it will sacrifice the ergonomics for dedicated servers.

[Shatur]

Yeah, I agree that we need to improve the ClientId ergonomics. I'd prefer to wait for 0.19 to play with resources as entities. Feel free to remind me about it later.