chore: add a BoM compatibility table to repository

[Lyokone]

Description

This PR allows binding a set of Firebase plugin versions into a single parent version named a BoM (Bill of Materials) version - an overarching version that internally specifies all versions of the FlutterFire packages that work together for that BoM release (much like Android).

This PR adds a Melos script bom which updates 2 files:

• versions.json which is a JSON file that can be consumed externally (e.g. the FlutterFire CLI) to get a match between a BoM version and all the other Flutter plugin versions and Firebase SDK versions
• VERSIONS.md which is a readable display version of the same information

The contributing guide has been updated with instructions on how to run a BoM release. A BoM release can be run at any time. We use Melos (melos bom) to automatically suggest the next BoM version number (based on the types of package version changes between the last BoM version and now) but it can also be overridden manually (melos bom [customVersion]).

A typical BoM would look like:

guillaume@macbook $ melos bom
New BoM version number (0.2.0): 0.2.0
JSON version data has been successfully written to scripts/versions.json
Version 0.2.0 has been generated successfully!

Why do we need this?

To solve customer pain points in regards to using compatible versions of the FlutterFire set of plugins together, e.g. this tweet.

Some alternatives have been considered in the past:

• Pub has no concept of peer dependencies, so we can't specify optional dependencies and their versions and have pub enforce that you use the right versions together, see Support peer dependencies  dart-lang/pub#1837
• We could make all packages have the same version numbering but you'd get versions of packages getting bumped even with no changes just to keep them the same version number, getting us quickly to the max 1000 versions of a package limit pub has and also getting us to the pub rate limiting of publishing too many packages at once.
• We could make a new package that depends on all the FlutterFire packages with the correct exact versions specified and you just use that package instead, and, while that would work there's the issue that your Dart code would get tree shaken to remove code for FlutterFire packages you don't actually use but the native parts of the FlutterFire plugins won't since they all get built and included in your app by flutter regardless of whether you use them in Dart or not because of how the plugin system in Flutter works, so you end up with every single Firebase service included in your native build.

Recently however we've been in a good position where the FlutterFire CLI has become the defacto way to do a bunch of things with FlutterFire and so we're able to explore solving problems like this with the CLI instead.

[russellwheatley]

Nice, just a few things from me 👍

[Salakar]

Based on chats internally my feedback would be:

• can we write the script in Dart, we already have a root pubspec, no extra files or setup needed other than the script file, others not familiar with bash can pick up making changes safely + code would work on any platform, e.g. Windows
• rename versions.mdx to VERSIONS.md to match naming convention of other root MD files
• move versions json out to a separate json file, perhaps next to the script, e.g. ./scripts/versions.json
• detach BoM versioning away from main release process, allow us to run normal releases regularly and group a bunch of releases into a single BoM at a different schedule to regular releases, e.g. around key events such as I/O
• BoM versions auto determined based on diff of versions of packages in last BoM vs versions of packages now to be used in new BoM, e.g. if any packages had a breaking change then BoM would be major, same with minor & patch