Prepare all pieces of the snowflake pipeline for a second snowflake bridge

Right now there is one snowflake bridge, and its fingerprint is hard-coded in tor browser.

Eventually we will have enough load, and/or want more resiliency, that we want to set up a second snowflake bridge.

To be able to do that, I think we need changes at the client, changes at the snowflake, and changes at the broker.

[Edit 2022-03: the three items I list next are no longer quite the best way to do this ticket. See the extensive and ongoing discussions below for what we currently think is the best plan.]

(A) At the snowflake side, the snowflake needs to tell the broker which bridge(s) it is willing to send traffic to. Additionally, we either want to declare that each snowflake sends to only one bridge, or we need to add a way for the client to tell the snowflake which bridge it wants to reach.

(B) At the broker side, we need it to be able to learn from snowflakes which bridge(s) they use, and we need it to be able to learn from clients which bridge they want to use, and we need it to match clients with snowflakes that will reach that bridge.

(C) At the client side, we need it to tell the broker which bridge it wants to use, and (depending on our design choice in A above) we might also need the client to be able to tell the snowflake which bridge it wants to use.

(There is an alternative approach, where we assume that every snowflake is always running the newest javascript, so it is willing to reach every bridge on our master list. Then the broker doesn't need to do anything new, and we just need to add a way for the client to tell the snowflake which bridge it wants. I don't have a good handle on how realistic this assumption is.)