Adds Elixir linter

[frm]

Why:

• With the growing number of projects using Elixir, we should try to follow the
  same style guides across all of them.

This change addresses the need by:

• Adding a .credo.exs file containing a sample configuration.

Notes:

• This PR shouldn't be considered a definitive proposal, but an initial,
  open-to-discussion proposal.
• These rules haven't been battle tested, but they are the ones being used in
  atmos.
• The sample configuration was obtained from the .credo.exs file of the credo
  repository. It contains
  all the available linting options.
• I tried to base myself on the Ruby linter, but for the time being, it values
  consistency in the current project as opposed to an overall rule for all
  projects.
• I, sadly, still haven't found any rule that enforces trailing commas over multiline
  maps, function declarations and arrays.

[frm]

A small update on this: I've been trying out different configs. This is the one that seems to do well with a community style guide with some small tweaks to include some of our practices.

[zamith]

What does this do?

[frm]

I'm actually on the fence on this one and would like a second opinion. TODO comments, by default, make mix credo exit with status code 2 and the CI fail. Having exit_status: 0 still makes the check but the CI doesn't fail. Which means when you run mix credo it's going to output a warning and remind you. It's not considered a failed check.

[zamith]

Well, someone said that a TODO is a fuck you to the other developers. That being said, I myself have added them from time to time as a reminder to comeback to it.

I don't have a strong opinion either way, but do think that breaking the build because of it is a tad too much for my liking. So in principle I'm ok with this.

[zamith]

What are these about?

[frm]

By default, credo requires a @moduledoc with a given model's description. This setting disables that check.

[zamith]

That's something that Elixir tries to enforce as a good practice as well, and I like it, but for public projects, not for internal apps. I'm thinking if it would make sense to have an OSS linter and an internal linter. /cc @naps62

[gabrielpoca]

If this is the only rule, is it really worth it to have two linters?

[zamith]

Probably not. We can do with what we're using now for other technologies which is tests as documentation and forego documentation in the modules.

[zamith]

What is this for?

[frm]

Disables the enforce of a typespec (@spec) when overriding behaviours. An example would be to create a mix app with a module that contains use Application. The required start function, without disabling that check, needs to have a @spec specification.

It seemed odd to me, given the name of the check, but it doesn't seem to enforce the presence of a typespec in any other function. I couldn't find documentation for that as well.