0.4.0 --- follow openkal 0.10 (#10)

* 0.4.0 --- follow openkal 0.10

⚠️ A REPIN AND NOTHING ELSE, AND IT IS NOT OPTIONAL.

openkal 0.10 adds five declarations, all of them to interfaces this
implementation does not provide --- so nothing here has anything to implement.

What is not optional is the version. A version requirement in this ecosystem is
EXACT and does not float up, and `openkal' is the shared dependency of every
package in the graph. An implementation left at 0.9.0 while a consumer moves to
0.10.0 does not get its own older contract: the two are irreconcilable and
nothing resolves at all. So a specification revision moves the whole graph or
none of it, and this package is part of the graph.

* Bump the version this package calls itself, which the repin forgot

Same defect as openkal-opensbi and found the same way: the commit is titled
0.4.0, moves the openkal requirement to 0.10.0, and left `version' at 0.3.0.
A release tagged 0.4.0 whose manifest says 0.3.0 is a package that does not
answer to its own name.

Checked every self-version in the chain against what its consumers require.
These two were the only ones that disagreed.

Author: Sunrisepeak

mcpp.toml

@@ -15,7 +15,7 @@
 [package]
 namespace   = "mcpplibs"
 name        = "openkal-uefi"
-version     = "0.3.0"
+version     = "0.4.0"
 description = "An implementation of openkal on UEFI Boot Services, for applications the firmware loads before an operating system exists"
 license     = "Apache-2.0"
 
@@ -32,7 +32,7 @@ authors     = ["mcpplibs"]
 repo        = "https://github.com/mcpplibs/openkal-uefi"
 
 [dependencies]
-openkal = "0.9.0"
+openkal = "0.10.0"
 
 [build]
 flags = [