Issue title: Define and set the code style early on
 Issue body: #### Is your feature request related to a problem? Please describe.
Define the code style from the beginning of the project (aka now or ASAP) and set the guards that would "enforce" it. This has multiple benefits:
1. It will remove opinionated debates and potential flame wars
2. It will streamline contribution
3. It will save A LOT of time for both contributors and code reviewers by preventing redundant whitespace changes

#### Describe the solution you'd like
There is already `.editorconfig` in the project which is an amazing first step! It will set the tone for everything else.
However, it is a basic set of definitions which is easily "overridable", depending on the IDE and the preferences people set in their IDEs.

**Proposal:**
- [ ] At the very minimum, add the prettier config that would **extend** editorconfig
- [ ] I'd also suggest adding `eslint` to the project but that could be a potentially sensitive topic and I'd leave it to @getify to define his own set of rules and checks, rather than going with any predefined ruleset

**Next steps:**
- Add a script that would auto-format the code
- Add pre-commit hook that would automate that process
- Add a basic lint check using GitHub Actions

#### Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

#### Additional context
https://github.com/getify/youperiod.app/pull/28 is a WIP and a place where the initial discussion about Prettier config extending editorconfig should happen. Once complete and merged, this PR will: 
- at the very least add a config
- at best add both the config and the lint script

 Comments: 
 Comment 0: @nemanjaglumac I will add basic lint checking.
 Comment 1: > @nemanjaglumac I will add basic lint checking.

As I mentioned in the description, https://github.com/getify/youperiod.app/pull/28 is already up and is dealing with this. Feel free to contribute with suggestions.
 Comment 2: @nemanjaglumac ok set all the formatting rules.
 Comment 3: Beyond the settings in this small prettier config, what "defaults" does prettier apply? Moreover, if the prettier config extends editorconfig, and it's set to closely match the existing code style (which is mine, and which I think is *fairly* consistent throughout), then why would there be a huge code diff once prettier is applied? It should be a minor couple of things here and there.

I don't personally use (or even like) prettier, so introducing it to the project, while familiar and "standard" to many, creates a mental barrier at least for me (and possibly some other would-be contributors).

I understand why people like these sorts of tools, but I think they are solving a problem that this project does not yet have, and might not even have for awhile.

Having a consistent code style is a priority that falls well down the list (not unimportant, but not most important) for this stage of a project, IMO. So I'm wary to introduce this so early (or at all). I prefer to only do things when it can be demonstrated that it's needed. That goes for frameworks, libraries, tools, processes, everything. Think like the "lean model" in startups, for example. Only do the minimum necessary.

By contrast, there's likely only going to be a handful of folks who post PRs for JS code right now, and not that many PRs at a time, and I'll be doing code reviews of all of them for now. I think we could fix up during code reviews any significant divergences that would harm the code readability. I don't like to nitpick on small style differences when doing such reviews, and I'm fine if there's some variance (within reason).
 Comment 4: The same reasoning applies above to eslint. I have a personal eslint setup that I use -- I run it manually on-demand rather than constantly nagging me during code editing -- to help me catch some things I care about.

But just like I wouldn't force everyone to use exactly my same coding style just to contribute, I also don't think they should necessarily have to use my exact linting ruleset.

In my mind, things like code formatting and code linting should be optional and per-developer (within reason) for early and small projects. We're not building a huge enterprise app here that will have hundreds of developers and teams working on significantly modular sets of huge features independent of others teams.

So to me, linting and code formatting feel like "premature optimizations" for problems this project doesn't yet have, and might not ever have (tbh).
 Comment 5: For example, with linting, I personally have some rules I use (and some I wrote!) around things like nested ternaries. The code that I will contribute, will very likely adhere to those rules (although I sometimes deviate from my own rules).

But someone else who uses ternaries, might be able to do so in a slightly different form, and still be reasonable and useful code. I don't want to have to change my code to their style, or their code to my style, if both approaches are reasonable in and of themselves. I like to be more permissive and allow for some variance and free expression.

If things were wildly different in a PR, like someone was writing a very different kind of JS that was confusing compared to the rest of the code base, then it's something I think we could address in that specific PR. I don't see why it would need to be automated, though, at the tiny scale this project is at now (and likely will stay at).
 Comment 6: I hope these comments are not taken as dismissive or discouraging. I appreciate the effort being put forth to find meaningful ways to help this project, and I also understand and respect the feelings many have about why these sorts of tools/processes are so important, given their experiences on (probably large) teams and (probably complex) enterprise apps.

I am not even saying a "hard no" to any of this. Just sharing my hesitancy and my inclination to defer and be careful about introducing any project components/processes unless and until there's a clear and obvious need. We may get there on this topic, and we may even get there *soon*. But I'm not convinced we're there yet, or that it's inevitable.

So I remain skeptical, but open to the possibility, and certainly willing to discuss and/or revisit as things evolve.
 Comment 7: > Beyond the settings in this small prettier config, what "defaults" does prettier apply?

Two of the most common "rules" that I'm not aware that editorconfig can set are:
1. automatic semicolon insertion
2. single vs. double quotes

While forgetting to use semicolon can be even dangerous in some cases, single vs double quotes is more a stylistic thing used merely for consistency. From my experience, this is where most developers tend to disagree (apart from tabs vs spaces).

>  Moreover, if the prettier config extends editorconfig, and it's set to closely match the existing code style (which is mine, and which I think is fairly consistent throughout), then why would there be a huge code diff once prettier is applied? It should be a minor couple of things here and there.

Here's a preview of those changes: https://github.com/nemanjaglumac/youperiod.app/pull/1/files.
The biggest diff is around prettier putting expressions (or parts of an expression) in a separate line, which is something that I don't personally like as well but not sure how to control it either.

Changes like this where it adds a space make code a bit more readable, imo.
![image](https://user-images.githubusercontent.com/31325167/177563969-01a7ad3c-3bb3-4dda-b469-c1afddb599ad.png)

Bottom line is - there are probably ways to fine-tune prettier's "aggressiveness" for rules that were not explicitly set, but that's irrelevant now.

You're right - I've approached this "problem" from the angle of a large enterprise app with thousands of files. Let's see how the project grows and evolves. If the need for it **ever** arises, it will be trivial to implement these changes later on in the project cycle.
 Comment 8: We'll revisit this perhaps at a later time.
{'source': 'GithubIssues', 'repo_name_with_owner': 'getify/youperiod.app', 'issue_id': 1295600126, 'repo_stars': 370.0}