denormalize the offers collection in DB

If we're going to use Mongo, it does not make sense to use it as a
relational database. Therefore, it makes sense to include the relevant
information about the connected restaurant to the offer during creation.

This does mean that the data can become inconsistent when, for example,
the restaurant changes the relevant data, but this is something I think we
shouldn't worry about, because a restaurant changing its name or address is
really rare. Out of these 2 changes the name change is more likely.
with this data model, changing the restaurant name would mean that the
already posted offers will become invalid, which is usually a issue of up
to 5 offers, so no big deal if the 5 offers have the old restaurant name
when a restaurant does change its name. And if it does become an issue
we can implement functionality for name change that also changes all
already posted offers.

In fact, I don't think we will initially enable name change anyway.

And the tag linking didn't make sense in the first place. The tag table
has a totally different purpose (only tags that will become filter
check boxes are in that table) so it was unreasonable to connect them.
update dependencies to latest (compatible) versions
Merge branch 'master' into feature/new-design
update node app to use static JSON if no DB available
fix styling merge issues
Merge branch 'master' into feature/new-design