Make event_platform not rely on existing config

Looks like it's really on those two things:

• Filtered HTML text format for the user field field_bio
• field_image used for the featured speaker node type

So, if we'd provide the image field ourselves and make the field_bio allow any format (allowed_formats: { }), this issue can be fixed.

So for me, this patch fixes the issue. I just allowed any text format on the bio field and copied the standard profile's image field over.

BUT...

Having another field_image might not work for everyone, so we better choose a different name. Which one?

AND...

I also see that there are fields like field_weight or field_badge which would profit from more distinctive naming. Any project that already has an existing field_weight or field_badge might run into problems installing Event Platform on top.

It's probably better to drop the default field_ prefix on these fields and have them prefixed with either event_platform_ or field_ep_ or featured_speaker_ to make this project more agnostic.

Something else to consider here: When we convert this project to a set of recipes, we can use config actions to resolve these potential conflicts and/or make sure that any needed dependencies are available.

Mhm, this sounds nice. That would require more architectural changes I guess. Means we could put that on a roadmap for v2?

This would be great at wil simplifying providing content and allowing drush si --existing-config to work.
--existing-config does not work with standard only minimal and event_platform makes it harder to switch profiles harder since it depends on a hook_install.
hook_install is the reason --existing-config does not play well with the standard install profile.

Theme recipe: A recipe that adds content to a site based on a specific theme.

This makes it harder for the theme recipe to cleanly rebuild the site from config and reapply its content. So some items have to be handled with more care and it's easier to start from a good configuration.