instant_messaging: fix intra docs anchors (#3601)

Signed-off-by: homersimpsons <guillaume.alabre@gmail.com>

content/client-server-api/modules/instant_messaging.md

@@ -34,7 +34,7 @@ Usage of this event is discouraged for several reasons:
 
 ##### m.room.message msgtypes
 
-Each [m.room.message](#m.room.message) MUST have a `msgtype` key which identifies the
+Each [m.room.message](#mroommessage) MUST have a `msgtype` key which identifies the
 type of message being sent. Each type has their own required and
 optional keys, as outlined below. If a client cannot display the given
 `msgtype` then it SHOULD display the fallback plain text `body` key
@@ -261,15 +261,15 @@ number of possibilities for choosing a useful name. To ensure that rooms
 are named consistently across clients, clients SHOULD use the following
 algorithm to choose a name:
 
-1.  If the room has an [m.room.name](#m.room.name) state event with a non-empty
+1.  If the room has an [m.room.name](#mroomname) state event with a non-empty
     `name` field, use the name given by that field.
-2.  If the room has an [m.room.canonical\_alias](#m.room.canonical_alias) state event with a
+2.  If the room has an [m.room.canonical\_alias](#mroomcanonical_alias) state event with a
     valid `alias` field, use the alias given by that field as the name.
     Note that clients should avoid using `alt_aliases` when calculating
     the room name.
 3.  If none of the above conditions are met, a name should be composed
     based on the members of the room. Clients should consider
-    [m.room.member](#m.room.member) events for users other than the logged-in user, as
+    [m.room.member](#mroommember) events for users other than the logged-in user, as
     defined below.
     1.  If the number of `m.heroes` for the room are greater or equal to
         `m.joined_member_count + m.invited_member_count - 1`, then use