Have `buffrs init dir` use dir instead of the current working directory

[qsantos]

I was a bit surprised when buffrs init --lib units created Proto.ml and proto/ in the current working directory instead of creating a units/ directory, like Cargo would do.

The second blog post actually uses buffrs init --lib units and suggests it works (or worked) like Cargo.

The current behavior is a bit annoying, since it mean you need to mkdir and cd into the directory before running init. If that's okay, I would like for buffrs init to work as closely as cargo init as possible, even initializing a git repository if there is none. It might not be very useful for implementations, but libraries could definitely use that.

[mara-schulke]

The behavior is inspired by cargo init / cargo new – we have only implemented init so far

[mara-schulke]

Maybe we can implement buffrs new?

[vsiles]

Just to clarify the possible behaviors as we might want to distinguish package names from directory names. Right now:

• buffrs init in a directory named foo will initialize a Proto.toml with package name set to foo in the current directory foo
• buffrs init bar in a directory named foo will initialize a Proto.toml with package name set to bar in the current directory foo

First option is to go the new / lib way:

• buffrs new requires a mandatory package name and will create a buffrs project in a directory of that name, with a package name of the same name. I'd require the directory not to already exist to avoid having to check its content.
• buffrs init without a package name will perform like it does now, using the name of the current directory and setting things up in .
• buffrs init package_name will behave just like buffrs new package_name. We might allow the directory to already exist in that case. Unsure.

Now I read that the package section of Proto.toml files might go away. Would we keep the name around in that case, or use the directory name instead ?