Allow specifying project name in the dirconfig file

[Thuna-Cing]

This allows specifying the project name in the .projectile file.

It is backwards compatible as the older versions will parse the name as a comment.

All tests except one that also fails on origin are passing so I marked them as such. There should be a new test added to actually check that the project name is being parsed properly but it can wait until the rest of the change is finalized, similarly for the readme and the changelog.

---

Before submitting a PR make sure the following things have been done (and denote this by checking the relevant checkboxes):

• [x] The commits are consistent with our contribution guidelines
• [ ] You've added tests (if possible) to cover your change(s)
• [x] All tests are passing (eldev test)
• [x] The new code is not generating bytecode or M-x checkdoc warnings
• [ ] You've updated the changelog (if adding/changing user-visible functionality)
• [ ] You've updated the readme (if adding/changing user-visible functionality)

[bbatsov]

Isn't it much easier to set a custom project name using .dir-locals.el?

[Thuna-Cing]

Isn't it much easier to set a custom project name using .dir-locals.el?

.dir-locals.el doesn't work reliably in non-file buffers. (Also, it is just more convenient in .projectile in my opinion)

[bbatsov]

But at the cost of adding more complexity to an already complex thing. That's why I'm a bit on the fence about this. I wonder if it won't be simpler to introduce a new file like .projectile-info or something where additional project data can be stored aside from ignore/include stuff.

[Thuna-Cing]

Does projectile use (or intend to use) any information other than the project name? If it will also contain the projectile configuration in .dir-locals.el, then it might be worth it to create a different .projectile-info file but it seems overkill otherwise.

Besides, if we have so much information that a different projectile-specific file is necessary, I would lean more toward making .projectile a directory instead.

[bbatsov]

At some point I was thinking of making some more structured configuration file to replace .projectile, but I put this idea on the backburner as with .dir-locals.el we've managed to address 90+% of what was needed essentially for free. And it solves the most complex problem - keep in sync the configuration file and the runtime configuration.

[Thuna-Cing]

Hmm, I didn't realize just how often projectile-project-name was called. Then, instead of projectile-parse-dirconfig-file, a function that only checks for the name should be fast enough. I just made a new commit as a proof of concept, maybe that will be better.