arg type: change type of array arguments from [n]*type -> *[n]type

[gucio321]

imo it is more logical for programmers to say just &myArray than creating a new array with pointers to each element of our array

reffer #84

@AllenDang let me know if there was any reason for doing it this way.

[AllenDang]

@gucio321 It's a intuition decision, DragInt2 works with two pointer values in an array, so should be []*int, rather than a *[]int. If you did some tests, say place dragin2 with few other widgets which requires pointer type binding in same window, and they work flawlessly, I think it's ok to change the type.

[neclepsio]

The example should be modified to keep the same behavior as before: the DragInt and DragInt2 are no longer linked and r, g, b, a are no longer useful. The example itself demonstrates in my opinion that the change is good.

[gucio321]

@neclepsio it should work now

@AllenDang it depends on how exactly user should store values passed to cimgui.
1: Current state: dragint2 is a bundle of two diffrent properties that could come from two diffrent places (e.g. two fields of settings structure or something like that)
+ we preffer to use structures rather than hard-to-read arrays in go
- it is quit difficult and lets say... not really casual to create an array of pointers imo
2: This change: dragint2 is used to edit an array of strictly connected values... If the user would like to implement the above solution, he needs to create temporary array, pass it and update after imgui call.
+ easier to crete in code
- could be not flexible enough for go realities

Personally, after re-analysing the situation, I think that the current scenerio is good, but the second may be more universal.... I don't know what do do tbh 😄

@AllenDang you're the boss here, please, decide what to do 🙃

[AllenDang]

@gucio321 I agree your solution, *[]type is better

[gucio321]

ok, so lets go ahead and change this!

[gucio321]

okey, @AllenDang it is done now

[AllenDang]

LGTM