Add membership event to inital batch of events slated for batch persisting during room creation

[H-Shay]

This is a follow-on from #13800 and is part of the work to speed up initial room creation. This PR adds the membership event to the initial batch of events created for batch persisting when a room is created.

Formerly, the code called the update_membership function to create a membership event. This code now does relevant checks and transformations (which I pulled from update_membership) on the creator join profile, etc and then creates the membership event locally and adds it to the batch of events for batch persisting. As a reviewer convince yourself that all the relevant checks and transformations for a join/membership event have been applied in the new path.

[H-Shay]

I was somewhat unsure what to do here-The code for non-batched events here recalculates the state in case the third party rules sent a state event into the room. I wasn't sure if that was necessary for the batched event, and chose to replace the event using the same prev event ids, state, and auth ids as the batched event that was being replaced, to preserve the batch being persisted in an unbroken chain (ie
creation_event <--- batched_event_1 <----batched_event_2 etc).
My theory is that the next event sent into the room would resolve the state between the two extremities (the state event the third-party rules sent in and the last event in the batched event chain), but if this is not correct or acceptable the other alternative would be to try and fetch the state event that the third party event sent into the room, add it to the state map of the batched event being rebuilt and recalculate the auth events from that, but I think(?) that poses a challenge for the rest of the batched events in the chain who are relying on the batch being an uninterrupted chain.

[erikjohnston]

We're parking this for now, until we have a conclusion about how to handle the third party module problem.