Related to #6127.
New Approach with machine translations, we add the translations to the same object. This way we don't need an extra table to store the translations.
ex. title = { :en => "title", :machine_translations{ :ca => "ca-title", :en => "en-title"}}

Why?
The old change made us change the translatable_attribute method. And so it forced us to change a lot of the existing code to make it compatible and some points can't use that (eg component settings).
The new approach allows us to keep human and machine translations identifiable, and lets us use the previous translatable_attribute helper as it is and only change the internals of the method.

Changes in the PR:

• Created hooks after_create and after_update, that trigger jobs to start the machine translation flow.
• Create: When a translated_field is changed, we call MachineTranslationResourceJob job.

MachineTranslationResourceJob

• We call N x M MachineTranslationFieldsJob jobs where N translatable_fields and M locales available.
• We translate only when the default locale is changed. Why?

1. Default locale can never be empty, hence we have translations for the other locale at all times.
2. Since they all mean the same it doesn't make sense to call translations when other locales have been updated.
   That being said, there are a few other cases that are taken care of:

• Different cases that are covered here:
  Let's assume the default locale is en

Case 1:

• Duplicate translations are removed
  ie. In case machine_translations exists for a particular locale,
  ex. title = { :en => "title", :machine_translations{ :ca => "ca-title", :en => "en-title"}}
  and we update the title with title = { :en => "title", :ca => "ca- title" }
  Then the duplicate ca translation is removed from machine_translations.
  title = { :en => "title", :machine_translations{:en => "en-title"}}

Case 2:

• If the user removes the translation of a locale that isn't default locale, since we have removed duplicates the machine translation for the locale will be empty.
  We identify the locale that has been set to "" and trigger a job to get the machine translation for that.

You can see how it looks in each case,

MachineTranslationFieldsJob

• It calls the Decidim.machine_translation_service which in this case is the DummyTranslator.

DummyTranslator: We have a dummy translator that updates the field with machine_translations => { translation_locale =>"#{translation_locale} - #{field_value}"}

This is just to test the flow of machine translation and hence the storing operations are done inside it.
Jobs can be used to achieve the same if a different translation service is integrated.

Finally, incase there isn't human translation available, we look for machine translations in the translated_attribute to use it in the views.