Write dozer.lock

[Jesse-Bakker]

Currently, this always writes the lock file to the current working directory.
Ideally we would follow the dozer-config.yaml around, but that is currently
impractical because of the implementation of the -c flag, combining *.sql and
dozer-config.*.

[chubei]

With this implementation, I think we can get rid of BuildPath.

It was designed to contain all information of a specific dozer execution, so user can restart dozer and continue from checkpoint.
Now that the contract file is moved out of it, there's no way to use data left in there anymore, so it makes more sense to just remove BuildPath and put everything that was previously in BuildPath to the HomeDir.

[Jesse-Bakker]

If the contract is consistent with the endpoints, we can still re-use the build, the same way as when the contract was written to the build dir, I think.

[chubei]

Some minor comments

[chubei]

the same way as when the contract was written to the build dir

I didn't make myself clear.

Before this PR, it's possible to implement such a command:

dozer run app --build 1

where we compare the "current" contract with the contract stored in build v0001. If they are compatible, we start from checkpoint. If not, we report error.

Now that contract does not exist in the build directory anymore, such command is not possible. And this beats the purpose of the existence of build directories.

That's why I said we can get rid of BuildPath now. It's not useful anymore.

[Jesse-Bakker]

Ah, as there is only ever one live build, the home dir in practice becomes the build directory. Luckily the contents of the home dir are an implementation detail, so I will defer this to after versioning