Adding possability to use 64bit unsigned long long in nk_property_ull gui element

Using 32bit size signed is limited to `[−2,147,483,647, +2,147,483,647]` range.
It's not possible to have larger value than that in the current Nuklear.
Adding support for unsigned long long which is 64bit size will have `[0, +18,446,744,073,709,551,615]` range and open up more possibility for apps using Nuklear.
The function could be called `nk_property_ull(struct nk_context *ctx, const char *name, unsigned long long min, unsigned long long *val, unsigned long long max, unsigned long long step, float inc_per_pixel)`.

Adding this function would require:
```diff
enum nk_property_kind {
NK_PROPERTY_INT,
NK_PROPERTY_FLOAT,
NK_PROPERTY_DOUBLE,
+ NK_PROPERTY_ULL
};
```
```diff
union nk_property {
int i;
float f;
double d;
+ unsigned long long ull;
};
```

We have to think about not overflowing signed or wrap around unsigned values. [INT30-C](https://wiki.sei.cmu.edu/confluence/display/c/INT30-C.+Ensure+that+unsigned+integer+operations+do+not+wrap) [INT32-C](https://wiki.sei.cmu.edu/confluence/display/c/INT32-C.+Ensure+that+operations+on+signed+integers+do+not+result+in+overflow).

Start by locating the existing nk_property implementation, its nk_property_kind enum, and its property union in Nuklear's single-header library. Compare the current integer handling with the proposed unsigned long long API and review the linked INT30-C and INT32-C guidance. Done means the new property element supports the stated unsigned 64-bit range without signed overflow or unsigned wraparound.

Written by the indexing model from the issue text.