Update deploy to Glitch (formerly HyperDev) docs

[AngeloStavrow]

This pull request improves the documentation around deploying the Parse server example to Glitch (formerly HyperDev).

Rather than provide instructions on importing from GitHub and then updating the .env file, this commit embeds a Remix On Glitch button that will import the repository into a new Glitch project, and pre-populates the .env file with either the required parameters or placeholder values. Instructions for replacing the placeholder values follow.

This PR also explains that anonymous users can test this deploy process on Glitch without needing to create an account, and links to documentation on the technical restrictions for free Glitch accounts.

[AngeloStavrow]

👆 I am not clear on what to do about that conflict, am I right that it gets built on push?

[TomWFox]

The spacing after full stops is inconsistent, could you change it so that all sentences have one preceding space.

[TomWFox]

I think the reason the checks have run is because you are on the gh-pages branch rather than a new branch.

[TomWFox]

@acinader The changes to the docs look good to me but I don't know what the bundle.js file does/how the conflict should be resolved.

[AngeloStavrow]

Thanks for the review and fixes! Pretty sure that bundle.js is being compiled by a hook when I push to my gh-pages branch, so I'm going to pull in your changes and push to a new branch — unless it's easier to just delete bundle.js in the conflict resolution.

[AngeloStavrow]

Hmm, that was a failed assumption on my part. Even in a different branch, if I commit (the original) bundle.js file, it triggers a build:

$ git commit -S -m "Reset assets/js/bundle.js"
husky > pre-commit (node v7.10.0)

> [email protected] webpack /path/to/parse-docs
> webpack --mode production

Hash: c5fd720afec493ce4019
Version: webpack 4.12.2
Time: 1538ms
Built at: 03/11/2019 9:30:08 AM
    Asset     Size  Chunks             Chunk Names
bundle.js  129 KiB       0  [emitted]  main
Entrypoint main = bundle.js
 [60] ./_app/UI.js 6.61 KiB {0} [built]
 [61] ./_app/echo.js 3.22 KiB {0} [built]
 [99] (webpack)/buildin/module.js 497 bytes {0} [built]
[100] (webpack)/buildin/global.js 489 bytes {0} [built]
[102] ./_app/main.js 19.1 KiB {0} [built]
    + 98 hidden modules

Let's see what @acinader says about the conflict resolution, then! 🙂

[TomWFox]

So no one's quite sure what to do here, so I'm going to try resolving the conflict - I'll take the version from the base branch.

[TomWFox]

I'm not well versed with Travis CI but I did have a little investigate and I noticed that the builds always fail but they don't usually show up on the commit messages that it failed.

I wonder whether these are running by mistake as they don't seem to be serving any purpose but I could be completely wrong about that - just thought I would document my findings here.

Image for reference (from travis ci):