Filter all traces for a particular IMSI

There isn't anything as simple as that, but on a per-protocol basis it can certainly be done. For example:

• In Diameter S6a/S6d, 'diameter.User-Name==imsi' will get you the request. Then filter on that request's "diameter.Session-Id" value and you have the request/response for that IMSI.
• In RANAP messaging, first you'd need to find an IMSI-based procedure (typically within the Common-Id IE) and search for the SCCP association id to grab. Search for that association id, and you get the full dialogue.
• In policy control applications, typically it's the same as S6a except that diameter.Subscription-Id-Data would be used insead of diameter.User-Name.
• In Sigtran/SS7 applications, at the SCCP layer often you have E.212/E.214 translation in use. In those cases, the called/calling party address can be searched for, mapped to a TCAP transaction, then that TCAP transaction can be searched for to get the full dialogue. For E.164-translated exchanges, you might not have an IMSI number at all so it would again depend on the application you're tracing.
• In SGsAP, that protocol contains the IMSI in every single message in either direction (gsm_a.imsi==imsi), so it's dirt simple to trace.
• In S1AP, IMSIs appear in some types of procedures but not all. You'd typically need to map out temporary identifiers for these (M-TMSIs), map them to IMSI from previous exchanges, then sort out the UE Contexts based on the MME UE Context ID and the eNodeB UE Context ID fields, realizing that both can change throughout the context due to mobility events.
• For SIP, potentially you can get the IMSI out of a URI or would have to map it to a URI. From that, get related SIP exchanges on URI and take the Call ID from it to trace such a session.
• For GTP, the procedure is similar between GTPv1 and v2 but either way you'd need to search for IMSI first, from it grab the sequence number, map it to the Create Session Response, then from that response you have all the GTP TEID values to include in a subsequent display filter for all the requests/responses mapping to tunnels set up for a given subscriber IMSI.

And I could keep going. :)

My point here is that your tracing methodology will depend greatly on the protocol, especially if you want all signaling that relates to a subscriber rather than just messages that contain the IMSI verbatim.

Now, in a telecom context typically you have trace tools (eg: Tektronix) to do this, though depending on what you're trying to do it isn't impossible to just built these trace tools from scratch. It's definitely not built into wireshark proper, though.