add --analyze for dump pkgs info

[visualfc]

gopherjs build --analyze for print simply pkg info. --anylize --json print pkgs json info.

for #3

> gopherjs --analyze hello

<Size>	<ImportPath>
 56914	$prelude
  6947	github.com/gopherjs/gopherjs/js
   446	internal/cpu
   879	internal/bytealg
   454	runtime/internal/sys
  8489	runtime
  1055	internal/unsafeheader
119993	internal/reflectlite
  1619	errors
  4665	math/bits
  2106	math
 15438	unicode/utf8
 89933	strconv
  1017	internal/race
   457	runtime/internal/atomic
  2975	sync/atomic
 37844	sync
   441	unicode
287744	reflect
 12061	sort
 21539	internal/fmtsort
 10469	io
   890	internal/oserror
115310	syscall
  2377	github.com/gopherjs/gopherjs/nosync
165010	time
 99944	internal/poll
   631	internal/syscall/execenv
   893	internal/syscall/unix
  2309	internal/testlog
  1020	path
  8958	io/fs
 81367	os
126487	fmt
  2788	github.com/goplusjs/js_demo/em_struct

--analyze --json for print pkgs json format info.

type PkgInfo struct {
	Name       string   `json:"Name"`
	ImportPath string   `json:"ImportPath,omitempty"`
	Imports    []string `json:"Imports,omitempty"`
	Size       int64    `json:"Size"`
}

> gopherjs build --analyze -json hello

[
	{
		"Name": "$prelude",
		"Size": 56914
	},
	{
		"Name": "js",
		"ImportPath": "github.com/gopherjs/gopherjs/js",
		"Size": 6947
	},
	{
		"Name": "cpu",
		"ImportPath": "internal/cpu",
		"Size": 446
	},
        。。。
]

[nevkontakte]

I suppose that would work, although it would be better to output into a file on disk, rather than stdout. The way it currently is, the JSON data would get mixed with all the other outputs GopherJS may produce and separating them would be tricky.

[visualfc]

I suppose that would work, although it would be better to output into a file on disk, rather than stdout. The way it currently is, the JSON data would get mixed with all the other outputs GopherJS may produce and separating them would be tricky.

current start line with "anylize pkg: xxx"

[nevkontakte]

Sure, not saying it's not doable, only that it feels a bit inelegant.

There's also another option, which is to make a better use of the source map GopherJS produces, add all relevant information into it and use it with any sourcemap visualizer tool like https://github.com/danvk/source-map-explorer. Having thought about it a bunch I increasingly feel like this would be both more elegant and versatile solution to the problem than this PR or mine.

That said, any solution that exists and works is usually better than the most elegant solution that doesn't exist at all :)

[visualfc]

Sure, not saying it's not doable, only that it feels a bit inelegant.

There's also another option, which is to make a better use of the source map GopherJS produces, add all relevant information into it and use it with any sourcemap visualizer tool like https://github.com/danvk/source-map-explorer. Having thought about it a bunch I increasingly feel like this would be both more elegant and versatile solution to the problem than this PR or mine.

That said, any solution that exists and works is usually better than the most elegant solution that doesn't exist at all :)

modify --anylize dump simply info, --anylize --json dump json info.