Add new supported ACCTs

[QuickMythril]

Introduction:
Since one of Qortal's goals is to allow anyone to build onto the platform, it's understood that some people in the community will want to run customized or personalized versions of the software. As this is a fully open source codebase, there should be no problem for someone to do that, as long as the blockchain consensus is still unchanged. One of the important features of Qortal is the Trade Portal, which allows anyone to trade supported coins without needing to rely on centralized services or provide KYC. Qortal's ACCT system is generalized for compatibility with many different blockchains, so a community could add their preferred coins to be traded and distribute a custom version of Core and UI which includes those. Currently there are discussions with developers from several other blockchain projects, who may be able to assist with relevant code.

Problem:
Within the Qortal UI, there is a filter for available trades, which removes them from display if they were created by a node which is currently offline. This is to prevent someone from accepting that trade, and not getting a response, causing their coins to be temporarily locked until they are refunded. Previously, nodes submitted a "presence" transaction to the blockchain, to indicate they are available for trading, but this was later changed to a separate off-chain peer-to-peer protocol within the Core. This protocol now checks the trade to see if the AT hash matches the known supported coins. What this means for someone who wants to trade other coins, is that only nodes which are running the custom Core will allow the presence for those trades to propagate across the network. If two people who don't know each other wanted to make a secure trade, they would need to be directly connected as network peers, which may not be possible or desirable, otherwise the UI does not show the trades.

Request:
This pull request does not add any new functionality to the Core, except the ability for all nodes within the network to recognize presence for some new coins. This not does add any features involving sending, trading, or checking balances on these blockchains. The majority of the code is just placeholder, with the only important value being the AT hash. Everything else is simply added to ensure that the code compiles properly, and much of it could probably be set to null or empty values. With these trades recognized, people will be able to test their own additions more properly. The changes have passed all unit tests, and manual testing with various types of platform usage.

Alternatives:
This seems like the simplest and fastest way to solve the problem encountered when testing out trades on a new chain, however there may be other options that are more effective. If there is a way to recognize whether an AT is a trade, or some other type of AT, then any custom trade presence could be passed on by non-custom peers. With more changes, this could even be something that each node owner allows or blocks in their settings, similar to the options for QDN relay mode.

Rationale:
It's been decided that adding any new coins to the Wallet and Trade Portal must be approved by an on-chain vote from the community. As this is effectively a set of constants, rather than full support for the new coins, it may not be something that would require a vote. Additionally, by setting the AT hash for these specific coins in the main release, it prevents others from accidentally using the same hash for two different custom coins, which would result in those unrelated tradebooks being merged. It is worth mentioning that there is a preliminary vote running, which currently shows that a majority of respondents would support adding each of these three coins. Before the last Core update, they were around 65% in favor, and currently they stand at about 55%. Even considering that we'll need to wait for another few updates to get more accurate results, and the low number of voters, that indicates there is not a strong consensus either way. Adding these coins for "custom support only" would be a great way to allow people to test and become aware of the proposal, and encourage more people to vote, giving a better idea of what the community wants.

• Additional votes can still be posted, and the results can be reviewed at: qortal://app/VotingTest

[kennycud]

This is not the solution the development group is looking for. The development group does want to allow support for coins like this, Bitcoin forks. We want to use a generic solution that we are looking into right now. We will have to address issues with SupportedBlockchain.java and presence to make this happen.