[RF-DOCS] Active Record Migration Documentation (rails#51928)

- [x] We talk about transactions and how to disable them early on, as part of the first few paragraphs, that could be a subsection to add separation.
- [x] The guide goes into reversible early, before even talking about generating migrations and other basic stuff, and then later talks more about it. I think it's important to lay the foundation of change vs up/down, and the fact that migrations should always try to be able to be rolled back, but maybe we can do that without going into reversible that early in the guide, which complicates things further.
- [x] We mention bin/rails generate --help to look for more details, but we could mention specific generators also offer help too, e.g. bin/rails generate model --help or bin/rails generate migration --help
- [x] There's a small section about composite PKs, but there's also [a whole guide on it](https://edgeguides.rubyonrails.org/active_record_composite_primary_keys.html), we can add a link to it from the migrations guide at least for more info on the topic.
- [x] The section that talks about execute shows an example of a specific model Product.connection.execute, but we can call execute directly within a migration, that might be simpler to show.
- [x] We talk about "seed data " in setup & preparing sections, but never mention it before, or explain what seed data is. There's a section about seed data later in the guide, perhaps we can link to it to facilitate.
- [x] In "running specific migrations", bin/rails db:migrate VERSION=zomg actually raises a different error: Invalid format of target version: `VERSION=zomg`... might need a different example there for the unknown migration version error. (no need to show this invalid format one)
- [x] The section about referential integrity can likely be better explained, in particular I think it's worth mentioning that even though the "AR method/way" (the pattern, I mean) doesn't think such "intelligence" belongs to the database, foreign keys and unique indexes are generally safer at the database level. (and should likely have their counterparts explicitly added in code with associations and validations). I just don't want to convey that someone shouldn't be adding FKs & unique constraints, because not adding these can definitely bite you.

Other changes: 
- [x] Moved sections around 
- [x] Added a section about "Rails Migration Version Control"
- [x] Added a section about "Using UUIDs instead of IDs for Primary Keys"

Co-authored-by: bhumi1102 <[email protected]>
Co-authored-by: Bartosz Łęcki <[email protected]>
Co-authored-by: Cecile Veneziani <[email protected]>
Co-authored-by: hatsu <[email protected]>
Co-authored-by: Petrik de Heus <[email protected]>
Co-authored-by: Ahmad hamza  <[email protected]>
Co-authored-by:  Bart de Water <[email protected]>
Co-authored-by: Amanda Perino <[email protected]>
Co-authored-by: Andy Atkinson <[email protected]>
Co-authored-by: Jamie Gaskins <[email protected]>

Author: 11 people