docs: headless mode and windows installation guide

We now have headless mode in our app where users can run the desktop app
in there default browser but no mention of it is in the docs also we
miss the windows installation docs.
This patch adds docs on how headless mode can be used and also adds win
installation docs.

Makefile: Improve the app related targets

Enable sourceMap for frontend build

Instead of repeating the "npm run build" command in all the 3 app
related targets, we now create an app-build target for that, and also
run "npm install" in it, as it's a needed first step.

Now sourcemaps work in the developer console.
Co-authored-by: Ashu Ghildiyal <ashu@kinvolk.io>

app: lint fix

app: lint fix in main

Add headless mode

We want to open the default browser with the server URL when running in
headless mode. To do that this patch adds open package which helps open
the default browser with the default URL.

We want to run the desktop app in headless mode this commit does the
intial setup required around it that includes accepting a headless mode
flag,bundling the frontend build directory with the desktop app and
if in headless mode running the server with that build directory passed
to the server.
For args parsing we also add yargs as a dependency so that users can
run headlamp with the help flag and see beautiful messages about
different flags that we have.

docs/headlamp_light.svg: Add a white background

Now that Github has a dark mode, the Headlamp logo we were shipping was
not very well visible in it. Since we have no way of changing the logo
according to the theme being used, let's just add a white background to
the black text logo.

App server logging

When the server process quits early there is an error logged.
So you can see the return code, and signal that killed it.

Also stdout, and stderr from the server process are logged.

Update backend target to produce a server excutable when on windows

When we are on windows platform we want to generate an executable for
our server binary. This is also important for our desktop app to run the
server because a plain binary file is not executable on windows.
Thus this patch updates the backend target to produce a server.exe when
the OS is windows.
For the desktop app now that we have a server.exe when on windows we
want to ship that as well into our electron packaging and thus we need
to create an entry for that in the extraResources property in
package.json. Also we don't want to commit the server executable so this
patch adds that as well to gitignore.

Update _index.md for clarity

Go with @joaquimrocha's helpful suggestion
Co-authored-by: Joaquim Rocha <me@joaquimrocha.com>

Clarify the grammar of the first paragraph of the plugins documentation

Workload navigation

Now that it's possible to override the back button's link, we use it
for the workloads in order to make any details view that is visited from
the workloads' overview to have a back link to it. This way we have the
following example for when accessing a Deployment details:
 * if the details has been accessed from the workload overview table, the
   back button's link will load it again when clicked;
 * otherwise (i.e. when the details view is accessed directly or from the
   deployments view) it will navigate to the deployments list.

This component reuses the common/Link one, which now supports a state
and search properties, so we should pass those optional properties to
the ResourceLink as well.

The mentioned component will show a section with a back link which by
default will allow the user to go back to a resource's list view.

However, there may be cases where we want to link back to a different
view, e.g. when going from the workloads list into a workload type
resource's details view.

This patch maintains the default behavior for the link, but overrides it
if the backLink property is passed.

This will be useful if we need to pass any context from the current
view into a view we are linking to using this component.

Now that we have a route for each workload type and a sidebar entry to
select them, we need to make sure that sidebar entry is selected when
accessing the route.

This class was overridding the mentioned method because the details
view was only being linked from the workloads' list.
Now we have a new list view for the Deployment resources, so we don't
have to use the mentioned override anymore.

This is in order for this table to be consistent with the rest of the
project.

Login improvements

If the AuthChooser cannot perform the auth test because it times out,
then we show the error to the user and ask them to either try again or
go back to the previous view.

Instead of prefixing the requests' error messages with "Api request
error", just use the error's own message because the UI may want to
prefix it in a different way.

When choosing a cluster to authenticate to, if the chosen cluster was
unreachable and the user went back to the previous dialog, then when the
authentication attempt call was finished, it would could still redirect
the user when this component was already destroyed.

This patch cancels that effect if the user leaves the view.

If the AuthChooser dialog is still loading, the user should be able to
go back to the previous dialog if needed.

We want to be able to try to reach a cluster and fail after a
certain (custom) timeout when needed. This function will be used so
we have an earlier timeout in the login dialog.

build(deps): bump ini from 1.3.5 to 1.3.8 in /plugins-pkg

build(deps): bump ini from 1.3.5 to 1.3.8 in /app