Improve the CreateRoomViewModel by introducing predefined room types

### Your use case

The `CreateRoomViewModel` class is too specific to Element

From my point of view use one room state param to carry a room type is a mistake during the room creation process. I know it was like this from the beginning. Historically the room type was guessed from the room visibility (public vs private),
now the room type is guessed from the join rules (public/restricted/invite/knock). See [SetVisibility](https://github.com/vector-im/element-android/blob/develop/vector/src/main/java/im/vector/app/features/roomdirectory/createroom/CreateRoomViewModel.kt#L179).

Define specific room types in an enum would be better. Each room type would correspond to a set of matrix parameters (visibility/join rules and others). Element-Android would only list the ones displayed in the current implementation:
- Private encrypted room
- Private unencrypted room
- Public room
- Restricted encrypted room
- Restricted unencrypted room

The current selected type would be available in the CreateRoomViewModel state. It will improve the room parameters definition.

Currently the set of the params is deduced from the `state. roomJoinRules` value (see
[createRoomParams](https://github.com/vector-im/element-android/blob/develop/vector/src/main/java/im/vector/app/features/roomdirectory/createroom/CreateRoomViewModel.kt#L239)), which is not logic. For example, this method forces "Directory visibility" public because the join rule is public, which is the expected behaviour for Element. But if you want to let the user create a room accessible by link without adding it into the rooms directory in your application forked from Element-Android, you have to customize strongly this code...It would be simpler to be able to add a new room type and convert it to a set of params in `createRoomParams` method

### Have you considered any alternatives?

_No response_

### Additional context

_No response_