BFont: remove default values from ambiguous method

Noticed by Joachim Mairböck after I hastily merged change 7402.

Also add named variation instance selection for fonts loaded from memory
areas like there already is for files.

Change-Id: I76de22181dc39559956c25987165be2f8a8c4a37
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7493
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>

app_server FontManager: load all fonts and named-variants from a file

BFont::LoadFont can now use an index (0-based) and an optional named-instance (1-based)
to select the font variant from a file.
BFont::LoadFont can also use an index when loading from memory.

Change-Id: I0ce3eb6cc77d32cf43847416561eafe3063ca693
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7402
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Reviewed-by: Máximo Castañeda <antiswen@yahoo.es>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>

app_server: AppFontManager does not need a BLooper

Saves at least a thread and a few semaphores per app.

Change-Id: Ied43e5944471918b34b897722346a25d159090df
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6073
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

app_server: refactor font managers

Move common add/remove code to the base class and improve encapsulation.
Loading FreeType is the responsibility of the global font manager.
Rename FontManagerBase back to FontManager.

Change-Id: I9396112f01583e19d03011106fd1fa1e37958ee8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6072
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>

app_server FontManager: remove not owned family deletion

On adding a font, we may or not have other faces of the same family, so
we may be trying to add the new face to an already managed family. In
that case, we can't delete it when we get an error inserting the new
style.

This same code was already in place before the user fonts, but it's much
more unlikely to trigger, except maybe on purpose. A later patch
refactoring a bunch of things will join both into the base class.

Fixes #18169

Change-Id: I78053b6e941c18b952fc2bd64f393e26d3d53b0a

app_server: don't return FreeType errors

They don't code Haiku errors and they are positive.

Change-Id: Ibd9da5251117e8883262d8880bad3c88eea6c4a9

app_server: push FontManager knowledge to FontStyle creation

Change-Id: I98a68a894642147d398faf22591a22afef4c3ba2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6060
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>

app_server: new font code cleanup: includes and the like

Change-Id: I4b7f882fffc34be1984060838f13971c48d4abfc
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6059
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>

app_server: FontStyle lifecycle

FontFamily is babysitted by the FontManager. It doesn't own FontStyle
references, there's no place in it to release them.

FontManager owns a reference to the FontStyle, and it is in
fStyleHashTable. Putting a style there acquires a new reference, so we
can release the one from the new style. Removing a style from the map
releases the reference. We need to clear the map before shutting down
FreeType to get rid of our last references and let the styles die now
instead of afterwards to avoid double freeing the faces.

These solve the new crash from the previous patch. It didn't crash
before because even after the map was destroyed there were still
dangling references to the styles.

On removing a user font, the style will remove itself from the family
through the manager if that was the last reference, and the manager will
remove and delete the family if it has no more styles.

Change-Id: I460ff830fa8a8a5adb90dc8ea12120e1e50a5912
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6052
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

app_server: fix double deletion of font families

The managed families are already deleted (in a correct way) in
FontManagerBase, so it's unnecessary to do it in GlobalFontManager.

Fixes #18245, though it surfaces another problem.

Change-Id: I93f1dcd1e0c1ec8d0657f3db6b484662e50c3487
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6051
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

BFont: Minor code cleanup and autolocking for AppFontManager

* changed explicit locking to use Autolocker for gFontManager/fAppFontManager
in ServerApp, per comments in https://review.haiku-os.org/c/haiku/+/4790
* changed BFont::LoadFont (memory version) to use size_t for size and offset
* no functional changes

Change-Id: I438a4975d5bb1b2fa17bc54e9e171c31dadfeec5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6003
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>

BFont: allow loading of user fonts from disk or memory

This patch adds an API call to BFont, called LoadFont, that
takes a string path to a font file. The user fonts are managed
via a new class called AppFontManager that inherits from the base
class FontManagerBase but adds the methods to add and remove user
fonts from disk or memory. There is also a new method called UnloadFont
to remove a user font, but on exit of an app all user fonts should be
automatically cleaned up.

Global/system fonts are managed by the GlobalFontManager, which is
a new class that also inherits from the base class FontManagerBase,
replacing the old "FontManager" class.

A maximum of 128 user fonts may be loaded, and memory fonts
may not exceed 20MB.

There's also an overloaded version of LoadFont that accepts
an area_id and loads the font from memory. A size and offset may
optionally be provided to allow for an area that contains more
than just a font.

Change-Id: I6add42bdf0c0cefc0e2e2a4984fd848c3e7269e5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4790
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>