Netlify Dev: Add framework = "#custom" option

[RaeesBhatti]

- Summary
This is to clear confusion around usage.
If framework = "#custom" in netlify.toml dev section, the user must specify command and targetPort options as well and we'll throw an error if they're missing any of these.
If framework is not #custom and user has specified command and targetPort options, we'll throw an error and ask them set framework to #custom.
If dir flag is specified, we'll ignore all detectors and throw an error if targetPort or command is specified.

Fixes: #827
Fixes: #441
Fixes: #851
Fixes: #862
Fixes: #850
Fixes: #847

- Test plan

• New tests added.
• Run netlify dev in your project

- Description for the changelog

• Add framework = "#custom" option for netlify.toml's dev section
• Don't allow usage of --dir flag with command or targetPort config options
• Add more test
• Throw lots of errors for invalid config

- A picture of a cute animal (not mandatory but encouraged)
👻

[erquhart]

It sounds like our heuristics are getting thrown off. Do we know specific reasons why inferred build command and port didn’t work for the linked issues?

It seems ideal to address this by being very clear about what configuration has been inferred. If we do go the disabling route, consider adding an option for disabling heuristics (would need a sensible name not involving the word “heuristics”) rather than accepting a special framework name.

[RaeesBhatti]

Highlights

• Fixing the confusion around detectors and command, port, targetPort options
• When we're running with custom command and targetPort we don't know at the stage of redirect routing if it's a static server or a framework server, passing down value of framework and making sure it's present even when someone is using custom framework enables us to route to correct endpoint
• Making absolutely sure that the user can't get Netlify Dev config wrong. We're throwing errors with helpful and instructive messages to tell the users when they have a problematic config
• The static server settings were being overwritten and this was leading to confusion, we're making sure that the critical settings can't be overwritten in a way that causes confusion
• Mores tests, both unit tests and integration tests with larger overview. We're also testing create-react-app now to make sure that config works perfectly in a dynamic app, not just a static one.