Fixes #43

(cherry picked from commit e851e04b)

Will only affect libgtkhex >= 4.0, so it probably won't be necessary to
cherry-pick this for the ghex-42 branch.

Initial commit: custom statusbar with monospace support

See merge request GNOME/ghex!29

(cherry picked from commit 44e1d553)

(cherry picked from commit 14d5a567)

- appwin: cleanup: remove unused/commented-out function
- pastedata: cleanup unused commented-out function
- hexdoc: cleanup/remove commented-out code block
	This has been commented out since 2002 according to git-blame. I
	*think* it's safe to delete it now.
- hexdoc: cleanup: delete untrue comment
- remove explicit void casts for unused vars

And remove now-superfluous function.

- bump soname for ABI break in HexDocumentFindData
- bump glib2 requirement to 2.68 to utilize g_memdup2()

Let's just not expose any further public structs at all on a go-forward
basis, m'kay? Lesson learned.

Expand search options

See merge request GNOME/ghex!28

- For Save As dialog, stop focus from being stolen from the filename
  entry and over to the search box. Hopefully this bug will be fixed in
  GTK soon and this workaround can be removed.
- See: https://gitlab.gnome.org/GNOME/gtk/-/issues/4880

- Also: Refresh preferred columns of HexWidget when Clear clicked

- When closing a window with only 1 tab open, show the singular tab
  close dialog. This also now disallows the closing of a singular tab,
  leaving the 'no file open' screen,

Fixes #47 - not fully decided that this will be the ultimate approach
taken in the long run, but it works well enough unless and until a
better solution is worked out.

This gets the widget to work properly with language bindings.

Remove FIXME comment as a result.

Written primarily to support reading/writing block devices.

At this stage, there is no special mechanism for privilege escalation.
That is, a normal user will likely need to be added to appropriate
groups.

appwin: Tweak nag screen accordingly. Change messaging a bit.
doc: change hierarchical selection of buffer backend.
buf: document slight change in hex_buffer_util_new behaviour when a
non-existent plugin is requested (return NULL instead of falling back to
malloc).

ie, requesting data beyond the payload is a programmer error. Luckily
all this reveals is that we're *not* committing that error, but it's a
good sanity check to have in there.

It might work. Maybe.

"It might work. Maybe." --jwz

mmap: Clear errors when required
appwin: Use hex-document async functions so we get access to GError.

Was likely a bit of a hack from a long time ago to work around adding
additional signals... Porting to libadwaita revealed this issue.

Port to libadwaita

See merge request GNOME/ghex!32

These were very recently added and I marked them for translation with N_
but did not properly call gettext on them at runtime.

See #48
Next step is to port prefs dialog to AdwPreferencesWindow

This reverts commit e0adb958.

This is not the right approach. Will try to write a better patch making
the unfocused theme/unselected/bg color work better with dark style.

Un-highlight when another PRIMARY selection is made

Support middle-click paste for PRIMARY

Get rid of the distinction between :selected and :focus-within
colouring in the CSS stylesheet -- now that PRIMARY is used to de-select
selections in a similar fashion to GtkText & friends, we don't see as
many things appearing constantly highlighted as we switch from one hex
widget to another.

This may be revisited in future, as I do like the
light grey appearance when focus is away from the highlights; but the
kink I can't work out right now is that the context-menu activating
*also* makes the highlighting show up in the grey colour, which looks
almost invisible on dark mode, which is a usability issue I want to
avoid more-so than I want the unfocused selections to appear grey.

Newer apps w/ gtk4 often don't advertise at all that their paste data
contains ASCII (they only advertise UTF-8) so the odds that the option
will appear has gotten more unlikely in the past 12 months or so, so it
makes sense to move it.

It crashes at this time, and it's probably not a good idea anyway.