Separate the changeset logic from the insert/update logic

[RobStallion]

I think that we should remove all the __MODULE__.changeset calls this module makes or provide alternative ways for the functions to be called that allow users to do this step themselves.

If we do this the functions can be made more flexible. We could allow users to call functions passing a changeset or a map as a parameter, something that is common when it comes to interacting with the database in a phoenix application. Currently we can only pass a map.

This could be an issue when trying to build associations between 2 or more tables. Ecto.changeset has functions like put_assoc(changeset, name, value, opts \\ []) (and many others) which we would not be able to use with the module (not without a workaround anyway unless I am missing something).

I feel checking a changeset to make sure it is valid is one step and then using it to interact with a database is a separate step.

@Danwhy @nelsonic @Cleop @SimonLab Does anyone have any thoughts on the above? If I have missed anything in how this module is meant to be implemented or anyone has any thoughts (for or against the above) please let me know 👍

[Cleop]

I think you've raised a good point here @RobStallion, I think this is part of what I was struggling with in the testing process.

[Danwhy]

You're definitely right @RobStallion. The initial idea was to make it as simple as possible to use this module, but obviously calling the changeset in here removes flexibility for more complex uses.

This is relevant to/necessary for work I'm doing in #22, so I'm going to implement this at the same time.