Update ecto changeset

[mauricioszabo]

This fixes #7

I'm using Ecto.Changeset.validate_change instead of our version. This will make it forward compatible with future versions of Ecto (because, right now, we're using a documented API to create changeset errors), but this leaves two things to think about:

• Will we add Ecto as a dependency for this project? Or, it'll be only for development? (in this PR, I've made it a dependency for every env)
• Is there a better way to test for errors? Right now, we're testing Ecto's changeset format. Would this change in the future, we'll have a false negative on our tests

[tiagoengel]

As @williamgueiros mentioned I don't think ecto should be added as a dependency because not everyone uses the changeset feature. A better approach would be to have another module that depends on ecto, something like Brcpfcnpj-ecto. For now I think we should just keep it the way it was before.

Regarding your concerns, we need to document the lib only supports ecto 2.x now, Ecto will not change the format without changing the major version (3.x), if they do we need to update our lib too. The changeset stuff can be moved to another module in the meantime.

Please update the lib's MAJOR version and update the readme as to show the changeset feature on version 0.x supports ecto < 2 and version 1.x ecto 2.x.

[williamgueiros]

@tiagoengel You're right, the best Idea is create Brcpfcnpj-ecto, and move the stuff about ecto and add reference on Readme. @mauricioszabo what do you think ?

[mauricioszabo]

I think we risk creating a bunch of very small libraries, so I would just add ecto as a test/dev dependency, and document that it expects ecto

=2.0.0.

I would make this change, but I am in a road trip right now, so I have no access to a dev computer...

[williamgueiros]

close that, in favor of #17