Changing typedef int32_t bufsize_t; to typedef size_t bufsize_t; causes lots of compile issues.

[ioquatix]

e.g.

commonmark.c:146:21: warning: implicit conversion loses integer precision: 'bufsize_t' (aka 'long long') to 'int' [-Wshorten-64-to-32]
  realurllen = url->len;
             ~ ~~~~~^~~
commonmark.c:243:16: warning: implicit conversion loses integer precision: 'bufsize_t' (aka 'long long') to 'int' [-Wshorten-64-to-32]
      for (i = marker_width; i--;) {
             ~ ^~~~~~~~~~~~
compiling houdini_href_e.c
compiling houdini_html_e.c
blocks.c:298:29: warning: implicit conversion loses integer precision: 'bufsize_t' (aka 'long long') to 'int' [-Wshorten-64-to-32]
    b->end_column = parser->last_line_length;
                  ~ ~~~~~~~~^~~~~~~~~~~~~~~~
blocks.c:303:37: warning: implicit conversion loses integer precision: 'bufsize_t' (aka 'long long') to 'int' [-Wshorten-64-to-32]
    b->end_column = parser->curline.size;
                  ~ ~~~~~~~~~~~~~~~~^~~~
blocks.c:310:29: warning: implicit conversion loses integer precision: 'bufsize_t' (aka 'long long') to 'int' [-Wshorten-64-to-32]
    b->end_column = parser->last_line_length;
                  ~ ~~~~~~~~^~~~~~~~~~~~~~~~
blocks.c:828:25: warning: implicit conversion loses integer precision: 'long long' to 'int' [-Wshorten-64-to-32]
    return (i - offset) + 1;
    ~~~~~~ ~~~~~~~~~~~~~^~~
blocks.c:863:50: warning: implicit conversion loses integer precision: 'long long' to 'int' [-Wshorten-64-to-32]
  parser->indent = parser->first_nonspace_column - parser->column;
                 ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~
blocks.c:886:32: warning: implicit conversion loses integer precision: 'bufsize_t' (aka 'long long') to 'int' [-Wshorten-64-to-32]
        chars_to_advance = MIN(count, chars_to_tab);
                         ~     ^~~~~
blocks.c:39:30: note: expanded from macro 'MIN'
#define MIN(x, y) ((x < y) ? x : y)

and a lot more.

It seems odd to use int as a buffer size (limited to around 2GB of input).

Can we fix this?

For a little more context, check #302.