Don't rely on dist.ini to contain a version

There are [Dist::Zilla](https://metacpan.org/pod/Dist::Zilla) plugins like [AutoVersion](https://metacpan.org/pod/Dist::Zilla::Plugin::AutoVersion), [Git::NextVersion](https://metacpan.org/pod/Dist::Zilla::Plugin::Git::NextVersion), [VersionFromModule](https://metacpan.org/pod/Dist::Zilla::Plugin::VersionFromModule) or [VersionFromScript](https://metacpan.org/pod/Dist::Zilla::Plugin::VersionFromScript) which make it possible to omit the `version` from `dist.ini`. Because of this, there are situations where the paths constructed from this (potentially missing) information in `dist.ini` point to nonexistent directories, which results in a failed package build. These issues can be avoided by passing the `--in` parameter to `dzil build`, which makes it put the output into a known directory which can then be used. This is what the changes in this pull request do.

For this known directory, I've chosen `.build/debian-build`, since this will also be removed when doing a `dzil clean`.

However, there is one issue this does not solve, and a related new issue:
* It's still possible that the version in the Perl modules/distribution differs from the version in `debian/changelog` (a [Dist::Zilla::Role::VersionProvider](https://metacpan.org/pod/Dist::Zilla::Role::VersionProvider) plugin which takes the version from `debian/changelog` could solve that one though).
* Version providers like `AutoVersion` or `Git::NextVersion` produce a version based on the date or a tag in the Git repository, respectively. This might result in source packages that cannot be built, or that result in packages with different versions in the Perl modules/distribution depending on the date they are built on. So maybe it would be a good idea to emit a warning if no version in `dist.ini` is found, since this _might_ indicate that the version is not 'stable', but I would not enforce it, since there are version providers which don't cause this kind of problem.