0.4.0 --- follow openkal 0.10 (#13)

* 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

The previous commit is titled 0.4.0, moves the openkal requirement to 0.10.0,
and left `version' at 0.3.0. openkal-musl 0.11.0 requires openkal-opensbi
0.4.0, so releasing this as-is would tag a 0.4.0 whose manifest says 0.3.0 and
leave that requirement pointing at a package that does not answer to the name.

Found by checking every self-version in the chain against what its consumers
require. It is the only one that disagreed.

Author: Sunrisepeak

mcpp.toml

@@ -14,7 +14,7 @@
 [package]
 namespace   = "mcpplibs"
 name        = "openkal-opensbi"
-version     = "0.3.0"
+version     = "0.4.0"
 description = "An implementation of openkal on the RISC-V Supervisor Binary Interface, portable across every machine whose firmware provides one"
 license     = "Apache-2.0"
 
@@ -33,7 +33,7 @@ repo        = "https://github.com/mcpplibs/openkal-opensbi"
 # The contract, not an implementation of it. Declaring it turns a version
 # mismatch into a resolution-time message rather than a link-time one.
 [dependencies]
-openkal = "0.9.0"
+openkal = "0.10.0"
 
 # ⭐ WHAT RECEIVES CONTROL, WHICH IS A STATEMENT ABOUT THE PROGRAM.
 #