feat: collection hashing for multi instance support

[GerryWilko]

🔗 Linked issue

fixes #3273

❓ Type of change

• 📖 Documentation (updates to the documentation or readme)
• 🐞 Bug fix (a non-breaking change that fixes an issue)
• 👌 Enhancement (improving an existing functionality like performance)
• ✨ New feature (a non-breaking change that adds functionality)
• ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

This PR aims to address issues related to multiple running instances of Nuxt connecting to the same collection database by optimizing the module initialization and removing the need to drop all content tables and recreate each time.

I have proposed moving the collection hash into the resolveCollection function and using the first four safe characters as part of the table name. This allows collections that have not been altered to be left untouched during initialization allowing for multiple connecting Nuxt instances to run the module without interfering with each other.

Do let me know if there is anything you would like me to change here.

📝 Checklist

• I have linked an issue or discussion.
• I have updated the documentation accordingly.

[pkg-pr-new]

npm i https://pkg.pr.new/@nuxt/content@3276

commit: 5f26183

[farnabaz]

Thanks @GerryWilko for the issue and PR,
Adding hash to the table's name is not an ideal thing to do. As a user, I don't like to see hashes in my table's name. Also what if two projects share the exact same collection?

Instead of adding hash suffix, we can add support for a custom table prefix. This way in tests each instance can define its own prefix. Also this would be useful in production, you can share sam database between two or more applications.
Instead of adding hash suffix

[case-fastly]

@GerryWilko curious if you have any further thoughts on this? (per the comment above)