Deprecate (or possibly remove) `defaultContext` APIs & Behavior

[aaj3f]

Description

Core has decided for a few reasons that db (and server by extension) should not be responsible for managing a default context:

• defaultContext can be set on the "conn" level (i.e. for db or server, it can be set on the state machine that instantiates ALL ledgers managed by that instance), and it can also be set on a "ledger", and it can also be re-set on a ledger (or even on a conn if you restart the instance). This ends up causing significant confusion for users. It's really hard to tell what the effective context was at any given query/transaction point, and it means on one ledger you can transact X and query Y and get totally different results than if you transact X and query Y on another ledger
• defaultContext causes a massive headache for signed transactions (in fact, it's effectively impossible to validate that a signed transaction was valid if all you have is the signature and the transaction, because the transaction got expanded against an invisible defaultContext -- as opposed to, say, an @context included inside the transaction itself)
• For other verifiable credential reasons, we had to treat /create and /transact syntax differently, so that /create looked like opts: { defaultContext: { ... } } and /transact looked like defaultContext: { ... }

While use of the endpoints will be deprecated (or removed from mention) in docs and internal tooling client code, we should also (at least) make the APIs private and/or simplify our txn/query expansion code by simply removing the capabilities altogether.

[mpoffald]

This was completed by https://github.com/fluree/db/pull/701 and https://github.com/fluree/server/pull/24