Remove / simplify parts of the elixir introduction

[riverrun]

Parts that I think we can remove:

• the {:module ...} return value when defining a module
  • this takes up space and does not give any useful information to the user
  • maybe we can keep it for the first example and then add a comment saying that it will not be shown in the next examples (similar to the comment about the BREAK menu)
• variable scope
  • this is something that the user can learn about later
• example of writing a mix task
  • this is something that the user can learn about later
• mix format section
  • instead, add a list of useful mix tasks to the mix section and add mix format to that list

Parts that we can simplify:

• dates and times
  • introduce the subject by looking at DateTime, and then add links to the docs for the other date / time types
  • this will use less space and will focus on the most important points - at the same time, the user will easily be able to find any further information that they need by following the links
• sigils
  • let the reader see that the ~ introduces a sigil and then provide brief examples of using the regex and string sigils
  • again, this is a matter of reducing the space used and focusing on the key points

[wintermeyer]

variable scope

this is something that the user can learn about later

Do you mean by "later" in the chapter or in the book?

[riverrun]

In the case of variable scope, "later" could also mean outside the context of the book.

Also, instead of having a whole section covering variable scope, we could just add comments to code where scope might be confusing. It looks like the book is intended for experienced programmers, and I don't think variable scope is going to be that confusing.

In the case of writing a mix task, "later" means later in the book (as long as we can think of a reasonably practical example).

[wintermeyer]

In the case of variable scope, "later" could also mean outside the context of the book.

We need to cover variable scope because I expect many Rails developers to read the book. There you have @foobar variables which are accessible anywhere. We have to make clear that this is not the case in Phoenix.

[riverrun]

I still don't think we need a whole section to cover variable scope, but I will keep it as it is for the moment.