Filterable "text" field conflicts with text components

Due to the fix for MC-269401, the set_written_book_pages function now expects a filterable containing a chat component, instead of containing a string. This causes ambiguous situations because both the filterable and chat components read a "text" field, and the former will take precedence.

How to reproduce

1. Create a data pack with an item modifier that appends 4 pages to a written book

   {
     "function": "set_written_book_pages",
     "pages": [
       { "text": "I'm a simple string" },
       { "text": "This won't be colored red", "color": "red" },
       { "selector": "@a", "color": "red" },
       { "text": { "text": "This works", "color": "red" } }
     ],
     "mode": "append"
   }

   {
     "function": "set_written_book_pages",
     "pages": [
       { "text": "I'm a simple string" },
       { "text": "This won't be colored red", "color": "red" },
       { "selector": "@a", "color": "red" },
       { "text": { "text": "This works", "color": "red" } }
     ],
     "mode": "append"
   }

2. Get a written book in your hand and apply the above modifier:

   /give @s written_book
   /item modify entity @s weapon test:book

   /give @s written_book
   /item modify entity @s weapon test:book

3. ⚠️ Notice that only the 3rd and 4th pages have red text. In the 2nd page, the color field is ignored, because the text field of filterable takes precedence over the text field in a chat component.

Code analysis

This is because both Filterable#codec and ComponentSerialization.CODEC have a "text" field, in SetWrittenBookPagesFunction these two are combined, due to the fix for MC-269401. This could for example be fixed by renaming the filterable field to "raw", which is also what the field is called in source.